Yes, iterators if available make our code clean and elegant and without overhead. We use iterators even on STL::vector. They are great. The minimum overhead you have with indexes is to calculate the address (char *)array + i*sizeof(row) + j*sizeof(item) And to double the increment and loop check since you have two variables ++i, i<h + ++j, j<w But if the underlying structure is not a plain array but a class you may have also boundary checks on the indexes. All this together can cost several CPU cycles. Also with a iterator/pointer you may use only a register (not a memory location) improving even more the speed. It depends on the cost of the inner code, if it is just a simple arithmetic calculation (1 cpu cycle) then I expect something like 10 times slower. All the GIL examples I saw use iterators and what I liked is that complicated image calculations can be stacked. If I have to flip the an image and convert it to B/W then traditionally I would do that in two steps, with Gil you do that in one step only, with nearly double performance. -----Messaggio originale----- 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 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users