Are iterators and ranges going to co-exist?

[Andrei Alexandrescu]

Peter Alexander wrote:
> == Quote from Andrei Alexandrescu
>> I don't understand this. If all you need is access to one
> individual
>> element, why are pointers inadequate for non-arraylike
> containers?
>> Knowledge of the container's topology is needed only if moving
> the
>> iterator around is needed.
>> Andrei
> 
> There's lots of reasons you need a cursor rather than just a
> pointer. I've already mentioned most of them.
> 
> - You can't do myContainer.remove(pointer). You need the cursor
> for efficient removal.

Ah, yes. Good point. But then I don't see why removing a range is less 
adequate than removing a pointer.

> - You can't do the random_shuffle thing I mentioned earlier with
> just pointers.

Random shuffle does work with pointers. Take pointers to elements, 
shuffle the pointers - and you have a winner. In fact pointers alleviate 
many instances of the "indexes with ranges are more expensive" problem. 
Contiguous containers that want to support removal can use integers. 
Node-based containers generally don't need to worry as nodes preserve 
their position.

> - You can't implement cycle_to with pointers (whether you need it
> or not).

I think this is a bit of a circular argument. First off, cycle_to is 
trivially implemented with ranges unless the definition of the problem 
requires use of iterators:

void cycle_to(R, F)(R r, F f)
{
     auto k = f(r);
     while (k != r)
     {
       swap(r, k);
       k = f(k);
     }
}

This doesn't consume more memory than the iterator-based counterpart 
because the number of range objects involved is constant.

> - You can't use pointers to construct ranges. For example, if you
> had a "Cursor findFirst(Range r)", you could use the value to
> construct before and after ranges. Pointers are no use here.

Good point.


Andrei