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
