Iterators Must Go

Steven Schveighoffer schveiguy at yahoo.com
Mon May 11 04:13:29 PDT 2009


On Sat, 09 May 2009 22:10:22 -0400, Rainer Deyke <rainerd at eldwood.com>  
wrote:

> dsimcha wrote:
>> == Quote from Rainer Deyke (rainerd at eldwood.com)'s article
>>> Although I like ranges, it looks to me like there are a couple of
>>> operations that would difficult to implement without iterators or some
>>> other way to specify a specific position in a range.
>>> Finding and erasing an element:
>>>   list.erase(find(list.begin(), list.end(), e));
>>
>> What's wrong with this?  Since list owns its range representation, it  
>> can know the
>> implementation details.  For a linked list, this will probably be just  
>> a pair of
>> pointers under the hood anyhow.  In other words, it's internally still  
>> an
>> iterator, just prettier looking.
>
> The following is semantically incorrect:
>   r = find(list, e)
>   list.erase(r)
>
> 'find' advances only the front of the range to the found element.
> Therefore 'r' is the range of all elements starting with the found
> element, but also including all elements after that.
>
> I would expect 'list.erase(range)' to erase all elements in the range.
> However, in this case I only want to erase a single element.  This could
> still be expressed with ranges, but it would require a different
> function.  For example:
>   find(list, e).eraseFront()
> Or:
>   list.eraseFrontOf(find(list, e))
> Or:
>   list.eraseOne(find(list, e))
> Or:
>   list.findAndErase(e)
> Or:
>   list.erase(take(1, find(list, e)))

I think Andrei's plans are for this last one.  You can srhink a range, so  
use the range primitives to srhink it to a 1-element range, then call  
erase.

>>> Splitting a container on a position:
>>>   iter = find(list.begin(), list.end(), e);
>>>   do_something_with(list.begin(), iter);
>>>   do_something_else_with(iter, list.end());

 From what I remember from the earlier discussions, Andrei's plan is for  
you to be able to subrange a range.  So for example, you have 2 ranges  
that overlap, return a range that is the intersection or complement.

I don't have huge issues with that solution, but I would point out that  
you now are depending on the developer to ensure the ranges do in fact  
overlap.  Of course, I could be wrong with my assumption (about Andrei's  
intent), maybe he has a better solution.

-Steve



More information about the Digitalmars-d mailing list