From: David Abrahams (dave_at_[hidden])
Date: 2005-06-17 09:27:53
"Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> "David Abrahams" <dave_at_[hidden]> wrote in message
> | 1. What does it take to get support for standard containers as ranges?
> | According to what I can see in the documentation, the standard
> | containers don't satisfy the range concepts. IOW,
> | begin(v)
> | isn't valid when v is a standard vector.
> | From what I can tell from browsing the implementation, the
> | requirement should be:
> | boost::begin(v)
> doens't it seem strange that a concept requirement is bound to a certain
Not really; especially if you show the "as-if" implementation of
boost::begin. But more importantly, as far as I can tell from the
code, that *is* the actual requirement! Otherwise, standard
containers don't satisfy the concept. It doesn't matter how strange
it seems if the alternative is inaccurate.
> | and the default behavior of boost::begin needs to be documented.
> it's documented in another document. I provided linke to in in the
> CVS version some time ago after you requrested it.
Sorry, can you provide a link (both to the page with the boost::begin
documentation and to the page in the main docs that links to it)? I
have the CVS version of Boost continuously updated at
> | 2. http://www.boost.org/libs/range/doc/style.html mentions
> | SwappableRange. What is that and where is it defined? The only
> | things I can imagine it meaning are highly counterintuitive.
> the document talks about terminology.
> A swappable range would be a range where the iterators are
a. You can't use a term you made up without defining it.
b. That's highly counterintuitive, _especially_ if you don't define
it. The notion of a "swappable iterator" is already weird, because
it means you can use iter_swap on the iterator, which doesn't swap
the iterators at all. To apply the same "logic" to Ranges at one
additional level of indirection -- without defining what you mean
and making a note that swappable is a strange idea -- borders on
the sadistic. Give naive users a fighting chance, please!
c. If you have no particular use for that concept in your
documentation, you shouldn't be naming it! That's a kind of
gratuitous name reservation.
d. None of these concepts are really crucial; "Range with random
access iterators" is almost as good as "RandomAccessRange."
> | 3. Where did you put the documentation that describes the conformance
> | of built-in strings, arrays, etc. to the Range concepts?
> in the "Implementation of range concepts".
Okay, that is an oxymoron right there. Concepts don't have
implementations. You need to rename this page. What is it really
Furthermore, I would never have thought to look there for this
information. One should be able to look at a concept definition and
understand which types will model that concept. That concept
definition may of course lead you to look at the implementation of
other functions, but it has to let you get ahold of one end of the
string, so you can follow it to its logical conclusion. That's why
the concept definition should say that boost::begin(s) is a
requirement... and of course it should link to the documentation for
boost::begin so the reader can find out what it takes to make that
function work, and deduce that it works for standard containers.
Finally, the fact that standard containers and iterator pairs conform
to the range concepts is a crucial usability feature of the library.
As such, it should be prominently mentioned in the introductory
material of the library's documentation, so that discovering it is not
a matter of deduction.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk