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