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

Subject: Re: [Boost-users] [range] questions about documentation and usage
From: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2012-11-02 15:16:42

Hi,

>
> 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.
As it can be interpreted as a pair of iterators...why not? It would be 
confusing if standard containers would not model a SinglePassRange. 
Ignore for a moment the write up in the documentation. And instead think 
about the sentence "Every squence that can be represented by an iterator 
to the beginning and the end, is a SinglePassRange". This already 
encompasses standard containers and many things more.
Now looking back at the documentation it is about how boost range 
formalises this concept in it's most abstract form.

This is the reason why the following:
>
> Nomenclature
>
> R SinglePassRange type
> r instance of a type R
>
> valid expressions
>
> r.begin()
> r.end()
is not a correct description of the abstraction, as the library is in 
fact more genral. So this description would be truely misleading as it 
would encourage the thinking of a SPR as something having methods 
begin() and end(). In fact the biggest achievement of boost range is 
that it strays from this path saying that it is boost::begin(r) and 
boost::end(r). It is a different way of thinking about the ranges. You 
are thinking about "how can i see that my class conforms to the range 
concept" and the document is about "what is a range?"

> 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.

> person who came up the with the name "concept" for what to me would 
> better
> be called "type requirement".)
This is your biggest misunderstanding is that you think about the range 
concept as type requirements even though th concept of a range is meant 
as a concept of a range.