Re: [Boost-users] [range] questions about documentation and usage

Subject: Re: [Boost-users] [range] questions about documentation and usage
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2012-11-05 05:01:44

On 02-11-2012 20:56, Robert Ramey wrote:
> Vicente J. Botet Escriba wrote:

>>> e) Somethings are not quite right - the thing that motivated this
>>> post is the confluence of containers and ranges.  There might
>>> be other things.
>
>> What do you mean?
>
> That's what I've been trying to explain here. I concede with limited
> success.  The documentation suggests that a SinglePassRange
> is sort of a "pair of interators".  But it turns out that any Container
> is also a SinglePassRange.  I'm sorry that's confusing to a plain
> reading. (note: understand how things are implemented so
> please don't re-explain it to me).  I would expect something more
> along the lines of
>
> Nomenclature
>
> R SinglePassRange type
> r instance of a type R
>
> valid expressions
>
> r.begin()
> r.end()
>
> In this case then a any container would full fill the requirements
> of a SinglePassRange.
>
> To be conforming, something like "struct iterator_range" would have
> to supply the same functions.  The notion boost::begin(r) and boost::end(r)
> seems out of place to me.  I haven't thought through all the implications
> of this as it would have rippled through the library design.  So cut me
> some slack here.
>
> Basically, I don't think the range library exploits the "concept" concept
> properly and the library suffers for it..  (off topic - I would love to hang
> the
> person who came up the with the name "concept" for what to me would better
> be called "type requirement".)

Well, the documentation was changed several times until we arrived at 
the current version that says boost::begin(rng) and boost::end(rng) has 
to be valid expressions.

How types are mapped such that those expressions become valid is a 
different matter. It depends on what headers you include.

You are welcome to suggest that containers should not be ranges and 
should require an explicit transformation to a range. Besides breaking 
tons of code, generate slower code, the it's just plain inconvenient.
A range is any type you can iterate over using two iterators. Surely you 
would expect that from containers.

regards

-Thorsten