- Why should a "c" programmer learn c++ ? (V2) - 9 Updates
- Are there any asm-instructions to support OOP - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 15 04:46PM +0200 > Whenever I need a two-dimensional array I simply use this one: > // comp.lang.c++ message from Gianni Mariani Nov 24, 2005 at 9:21 pm > // http://groups.google.com/group/comp.lang.c++/msg/a9092f0f6c9bf13a I think there are convenient ready-to-use libraries for 2d-arrays# or matrices. |
| Siri Cruise <chine.bleu@yahoo.com>: Sep 15 07:51AM -0700 Punishment for past life transgressions. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed |
| olcott <NoOne@NoWhere.com>: Sep 15 09:52AM -0500 On 9/15/2020 9:46 AM, Bonita Montero wrote: >> // http://groups.google.com/group/comp.lang.c++/msg/a9092f0f6c9bf13a > I think there are convenient ready-to-use libraries for 2d-arrays# > or matrices. I loved its simple elegance. I used it in my deterministic glyph recognizer to hold the screen pixels. -- Copyright 2020 Pete Olcott |
| Richard Damon <Richard@Damon-Family.org>: Sep 15 12:12PM -0400 On 9/15/20 10:10 AM, olcott wrote: >> know how to use it. > I don't rememeber ever needing to do this, I simply used the default > assignment operator(). The difference is that vecA = vecB; will make of new copy of all the data in vecB. vecA = move( vecB); will transfer without copying the data from vecB, and vecB now is without its data, but has been reset to some sort of 'default' state. If vecB is about to go away or get a new set of data, this can save processing, if not this 'optimization' migt get you into trouble. |
| olcott <NoOne@NoWhere.com>: Sep 15 11:23AM -0500 On 9/15/2020 11:12 AM, Richard Damon wrote: > without its data, but has been reset to some sort of 'default' state. > If vecB is about to go away or get a new set of data, this can save > processing, if not this 'optimization' migt get you into trouble. I can't imagine any need for this that references would not handle. -- Copyright 2020 Pete Olcott |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 15 09:50AM -0700 > On 15/09/2020 08:28, Juha Nieminen wrote: [...] > same way that: > int* p; > doubles as 'pointer to array'. Agreed. > int (*p)[][100]; > int i,j,k; > p[i][j][k]; No, a pointer to a 2D array and a pointer to a 3D array are two different things. A pointer to a 2D array might double as a pointer to *an element of* a 3D array. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 15 09:53AM -0700 > On 9/15/2020 5:06 AM, Ben Bacarisse wrote: [...] >> Likewise, a pointer to an array of 100 ints is not a pointer to 2D array >> if ints, it is a pointer /into/ (i.e. to one member of) such an array. > I don't see the difference. Read section 6 of the comp.lang.c FAQ <http://www.c-faq.com/>. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 15 01:28PM -0400 > On 9/15/2020 5:06 AM, Ben Bacarisse wrote: [...] >> Likewise, a pointer to an array of 100 ints is not a pointer to 2D array >> if ints, it is a pointer /into/ (i.e. to one member of) such an array. > I don't see the difference. The following might help, if you think about it: #include <stdio.h> int main(void) { int twod_array[20][100]; int (*p)[20][100] = &twod_array; int (*q)[100] = twod_array; printf("p: %zu %zu %zu %zu\n", sizeof p, sizeof *p, sizeof **p, sizeof ***p); printf("q: %zu %zu %zu\n", sizeof q, sizeof *q, sizeof **q); return 0; } |
| Bart <bc@freeuk.com>: Sep 15 06:38PM +0100 On 15/09/2020 17:50, Keith Thompson wrote: > No, a pointer to a 2D array and a pointer to a 3D array are two > different things. A pointer to a 2D array might double as a pointer > to *an element of* a 3D array. I used 'double' in the same sense as the quote I replied to. And I showed you can apply 3 levels of indexing even though the type includes only two array levels. It is this extra level of indexing that is behind at least 99% of how C deals with dynamic arrays and with array passing. |
| scott@slp53.sl.home (Scott Lurndal): Sep 15 04:13PM >just load exactly the amount of bytes that you read, but a block of RAM >from around that location (I don't remember now how large it was, but it >might have been something like 64 bytes or the like). 64 byte on intel and AMD. 128 bytes on the processors we design and build (so we can preload the first 128-bytes of a network packet directly into a cache line from the NIC for high data rate packet processing). >it's not already in L1 cache, a block of memory will be read into cache at >once, and if your next access is within that block, it will be >extraordinarily fast, because the value will already be in L1 cache. I understand quite well how caches work, having worked with them at the hardware level in one way or another for forty years building mainframes, massively distributed systems and high-core count Aarch64 processors. >Then change the program to do the same, but just read the bytes in the >array consecutively from beginning to end. >The difference in speed is *staggering*. Indeed, however, this is an artificial benchmark that doesn't represent the vast majority of real-world workloads. >The reason for this is that in the first case every single read will cause >a complete cache miss, and is extremely slow. In the second case there will >be a cache miss only every 64th read or such. Every 8th read if you have a 64-byte cache line and are reading 8 bytes at a time. >Clearly you haven't actually tested the difference in speed that handling >an array of values directly has compared to making a function call that >handles one member variable at a time. No, I write code, not benchmarks. On the other hand, I've spent months running TPC-C and TPC-D to gather data to refine cache and memory subsystem designs. >Due to technical details it wasn't feasible to make these functions inline, >so they were implemented in their own compilation unit (which caused an >actual function call to be done when calling either one). LTO generally solves that problem. Sure, code will run faster sequentially. That doesn't help the vast majority of applications. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment