> With this approach you can keep your iterators on the
> stack (no dynamic memory allocation), and you avoid
> virtual function calls.
I don't think allocating all the iterators up front is going to be efficient
in voxel space, depending on the size of the array, since it's not
necessarily a given that all the voxels will be traversed. In addition, for
large arrays (it's not unusual to see volume data on the order of
1000x1000x1000), it may not be feasible to keep these iterators around at
all times.
Based on that, I would guess that you want to create the iterators lazily,
and you want to avoid the virtual function call. You might put a method on
the array class itself (can you do that?) that will return an iterator given
a set of voxel coordinates. Three simple compares could isolate what kind of
iterator to return, and I'm thinking there should be 14 different kinds of
iterators for performance reasons (faces and corners).
There's probably a way to use template metaprogramming to build all 14 of
those iterators without having to separately code them, but the engineer
side of me says that all 14 will be instantiated anyway, and the code
differences are minor, so it's probably a faster coding effort to make the
first one, then use copy/paste. Before the group moans about that statement,
let me say it's your decision whether to make a nice design, or get it done
in a short period of time. Beware of the additional testing/debugging burden
required for both approaches.
On another front, I bet you could use template metaprogramming to make the
decision of what kind of iterator to return at compile time, assuming you
aren't using a dynamically allocated array.
On yet another front, this is very distinctly in the realm of optimization.
You might want to put it at the end of the "to do" list on your program,
after everything else works correctly, if you haven't already done so.
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:07 EST