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