Iterators Must Go

[Steven Schveighoffer]

On Sat, 09 May 2009 00:15:19 -0400, Walter Bright  
<newshound1 at digitalmars.com> 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