Are iterators and ranges going to co-exist?

[Andrei Alexandrescu]

On 07/19/2010 04:24 PM, Peter Alexander wrote:
> On 19/07/10 9:47 PM, Andrei Alexandrescu wrote:
>>
>> The plan is to use ranges everywhere. Sorry to disappoint. If you can
>> find solid arguments for introducing iterators, of course it would be
>> great if you discussed them in this group.
>
> Well, you mentioned a few yourself in your article.
>
> - With ranges, you double the size of "iterators", which increases the
> memory usage of something like Boost.MultiIndex.

Agreed.

> - It makes certain algorithm interfaces awkward, such as rotate. I know
> you proposed to pass in two ranges, but to me that seems like an
> desperate attempt to force ranges into an interface that wants
> iterators. In the case of rotate, you've now burdened the programmer
> with assuring that the ranges are adjacent (which will probably involve
> introducing a local variable for maintenance/readability reasons), and
> you've also increased the amount of data you need to pass into the
> function by 33%, violating the "Don't pay for what you don't use"
> philosophy.

Phobos' bringToFront does not assume the ranges are adjacent. 
bringToFront is a strict generalization of STL's rotate.

> - You're returning more data than is often wanted from some functions
> (such as the planned find).

That's not necessarily a disadvantage, and I think in practice it's 
seldom an issue.

> - It makes something like STL's std::list::splice *very* awkward. To do
> splice in constant time (as you should) the "range" is going to need to
> know about the previous element to its front so that it can update the
> linked list. What is the planned interface for this?

splice is an internal method of the doubly-linked list. As such, it has 
knowledge and access to the list range's implementation and therefore 
has no problem wiring the pointers appropriately. (Note that splice does 
not work with just any ranges.)

> My biggest objection to this is that it is essentially an awkward
> attempt at abstracting iterators. Ranges are brilliant, and maybe you
> could even call them a superset of iterators, but just like we have
> vectors despite having matrices, and points despite having lines, we
> still want iterators even though we have ranges. They are simply
> different things.

I think the comparison is tenuous - I do agree that we have vectors vs. 
matrices etc., but that doesn't necessarily translate in convincing me 
that there should iterators vs. ranges. Pointers don't have a 
line-specific operation that may make them explode :o).


Andrei