Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at