Here's the solution to the user quiz. Aside from the memory bug, there's one main problem. A one dimensional array is indeed identical to a pointer, but a multi dimensional array is not. int array[x][y] is very different to int **array. In fact a pointer to a pointer is no array at all.

Whenever you access this construct, the program hits two different memory areas. This is much slower than using an array, which is a single contiguous memory area. There are further subtle problems with this coding style, so better don't use it in a real application.

If you do, you must use brackets, and you should use them even when not required by the language syntax. Otherwise either you or some other poor fellow working with your code will confuse this construct with a real multidimensional array, and then you'll get the nicest bugs and crashes.

To be on the safe side, use a normal multidimensional array for a static definition, and a single pointer for a dynamic definition, no matter how many dimensions.

I use this construct in many real applications, in fact my iPhone engine bases heavily on this kind of pointer to pointer to memory access relation.

There is a performance problem, but this has nothing todo with those pointers but with copying the data into the GPU memory and blocking the CPU in the meantime.

I just checked the access time on my very old iPhone 3G running iOS 4.1 and the difference between fixed array and pointer to pointer is not visible in the log (about 0.010 seconds to read and write into the memory).

I know that I can't compare a RISC CPU with an x86 CISC CPU, so I checked it also on my 2 Ghz Intel Dual Core Machine running Mac OS X 10.6.4, the result:
Read and write into the memory was about 0.001 seconds (both, fixed arrays and pointer to pointer).

Both versions had debug symbols and was build with LLVM 1.5 and Clang. No optimizations and no link time optimization.
I have checked the assembler code that was generated to make sure that the loops will be executed.
The test function has written PI into every member of the array and then read the value and saved it into another float.

Output:
OS X:


iPhone:


Could you please explain what is so much slower? Because I really can't reproduce this (was too lazy to boot windows, so I haven't tested it with Gamestudio).
I use this construct very often, and if there is really a performance problem with that, I wish to know about that so I can avoid this.

0.001 seconds seems very slow even for copying a huge memory area, regardless of the method.

Anyway, the reason of the performance problem is the CPU cache. When you access a memory location, a cache line is filled. The next time you hit that area, the CPU reads from the cache instead of the memory.

The more different memory areas are accessed, the more cache lines are created. When the cache is full, old lines are removed and new lines filled. This causes a severe performance hit. That's why in time critical programs, especially 3D engines, the programmers avoid reading from different allocated memory areas at the same time. Of course this effect is the worse, the bigger the memory areas are and the more fragmented the memory is.

Of course there are more problems with that method - for instance, you'll risk a crash when you initialize that construct with a memset call, as you would do with an array. I would not use that method for non time critical applications either.

Well, I'm sure that it is much faster, but the log function needs some time too. On the iPhone it also needs to tether the log message to the host and burn some CPU time on this task.


Thanks for explaining, I didn't know about this issue and I will try to avoid this kind of pointer to pointer relation in the future too.

Edit: Another wish for the A8 compiler: Closures and thread-safe engine functions.
Both together would be perfect for multi-threaded projects. Or even better than Closures, Blocks: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf

@JCL:
Ok how to use a single pointer for a dynamic definition?

when i use:

int *array;

and try to write/read like this:

(array[1])[1] = 5;

i always get:
Subscript requires array or pointer type.

You can use something like this:



While n is the number of elements, row the row and col the column. To make it more convenient, you can use this makro:



Of course you need to allocate the memory as one dimensional array. Like this:

@JCL

I found a bug. Maybe. I can move through all my models, even if I am setting BBOX or Polygon in WED/SED. Anyone else has this problem?

Really? REALLY? This sounds weird. In fact, afair I learned that multidimensional arrays are nothing else than an array of pointers to other arrays, which don't necessarily have to be in one contiguous memory area.
However, if this is true, what you say, why can I use pointers to pointers in function parameters if I want to pass an array to a function? And if that makes a difference, then Lite-C should support arrays with indefinite size as function parameters.
However, I think whenever I saw an example how to create a multidimensional array at runtime, it was always like Rackscha did it. If it is true what you say creating a "real" multidimensional array would look like this:

Is that right? But in this case, the pointers to the arrays would be a waste of memory in comparision to a 1-dimensional array of the size sx*sy.

I am sure this is wrong, no compiler that I know uses an array of pointers to other arrays or something like your code for substituting a multidimensional array. All normal C/C++ compilers support multidimensional arrays natively.

So this means that multidimensional arrays are indeed just the same as a one-dimensional array, just that it's preceeded by an array of pointers? In this case multi-dimensional arrays would indeed be just a waste of memory and wouldn't make sense to use as it would always be better to use one-dimensional arrays. But then, why do they exist? o.O