On Sat, 09 May 2009 00:15:19 -0400, Walter Bright
<[email protected]> wrote:
Steven Schveighoffer wrote:
You're assuming an iterator does not know its bounds.
That's right. That's the usual design, which is based on the pointer
model. Pointers do not know their limits.
Yes, that model is not as safe. That's not the model I'm referring to.
Maybe I should call it something other than iterator. How about cursor?
Or range? <g>
Nope, a range cannot go backwards or forwards at will. It can only do one
or the other, shrinking one end.
There are definite reasons to use containers in ways that don't involve
std.algorithm, where something that has the easy ability to move back
and forth N times without weird subrange operations.
I'm thinking of a structure with either a pointer to the container for
bounds checking, or a range and pointer combined (where the invariant
is that the pointer is always within the range).
I'm not saying ranges are not great, i think they are a HUGE step
forward, but the statement "Iterators must be eliminated" may be too
harsh. Perhaps the unchecked iterator, yes (but you may want to allow
it in certain performance-critical code).
If you had an iterator that knew its beginning and end, then the whole
paradigm of:
for (iterator i = begin; i != end; i++)
doesn't make much sense because of the redundancy.
STL iterators can be used for more than just iteration. They also serve
as cursors, or pointers to specific elements. If you add the ability for
them to check their own bounds, then they become as safe as ranges, and
can be used as general purpose pointers for things like insertion,
deletion, bi-directional traversal, things that ranges can do but are
clumsy at.
You still have the interchangable-with-pointer concept burned into your
brain :)
Think more like this:
for(cursor i = begin; !i.end; i++)
-Steve
