Re: [boost] AlRangeExandrescu?

Subject: Re: [boost] AlRangeExandrescu?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-07-24 11:41:08

Stewart, Robert wrote:
>>> That would limit ranges because there are ranges that are not
>>> pairs of iterators.
>> All ranges can be expressed as pairs of iterators, so I hardly
>> see how that limits anything.
> 
> Not true.  Some ranges can be generated on the fly based upon a
> predicate (either provided or built into the range type).  Ranges
> in the Boost.Range library are what you've described, but those
> in Andrei's scheme are not.

I don't see how your message disproves what I said (nor actually, how it 
is related at all).
Boost.Range is just a set of tools to make it more practical to 
manipulate iterators pairs, which can represent ranges. Alexandrescu 
offers to ditch iterators and directly define first-class ranges.
Yet, in terms of expressiveness, a pair of iterators is not less 
expressive than Alexandrescu's ranges (discuss below). The only gains 
there might be are ease-of-defining (but then, if you accept my argument 
iterators are needed anyway, that gain is moot) and efficiency (which 
becomes moot too if you allow the two iterators of the pair to be of 
different types).

>> The issue is that expressing a range as a pair of iterators may
>> not always be optimal.
> 
> Expressing a range as a pair of iterators is not always possible.

They actually seem to be mostly equivalent, except Alexandrescu ranges 
lack the ability to compare positions.

Do you have a single example of a range that can be expressed with 
Alexandrescu's concepts but not with iterators pairs?

Not that unlike what the "Iterators must go" slides claim, iterators can 
implement the Stride operation just fine.