Andrea Denzler wrote:
Working with indexes is defintively easier and more confortable. And probably in many situation the overhead is not worth to be optimized at all.
I only was surprised when you said there is a performance gain using indexes.
But I hardly would write something like this (from your array.cpp example)
for (int i = 0 ; i < h ; ++i)
for (int j = 0 ; j < w ; ++j) {
array[i][j] = uni() ;
}
You are loosing performance unless the compiler is so intelligent to avoid the multiplication at each step. When performance is really an issue then I first re-think the algorithm, after I check the produced assembler listing to see what the compiler did. In the example above at each step you have to calculate this address:
array + i*rowsize + j
If you are lucky the compiler can produce code that does this in one instruction set, if not you will get an overhead. Again if h and w are low values you will not notice it.
This example is of course much faster, and yes, it is not elegant nor clear.
int *p=array*,**pend=&array[h][w];
while (p < pend)
*p++ = uni() ;
The standard algorithms use iterators; An array implementation that translates iterators to indexes and expects the indexes to be converted back into pointers is questionable to me. Especially when my trivial test code showed the multi-array implementation was 10-20 times slower. This slow down is way more than I expected. The multi_array implementation is extremely scary to me because it does not seem to be low overhead at all. -- John