"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:ull5bnykl.fsf@boost-consulting.com... | | 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 namespace?

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 http://www.boost-consulting.com/boost.

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

Clearly.

A swappable range would be a range where the iterators are swappable.

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 describing? 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

Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:

On Fri, Jun 17, 2005 at 10:27:53AM -0400, David Abrahams wrote:

...

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

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.

I don't think that the requirement should be

boost::begin(v);

since functions cannot be partially specialised, and only the overload mechanism together with ADL is available to use a user-defined begin-function. In cases like this I regard the requirement

using boost::begin; begin(v);

as the correct one:

- now standard containers fulfil the requirement; - and used-defined versions of begin are taken into account.

boost::begin is defined to look up a user-defined function via ADL. This was extensively discussed on the mailing list. I'm not saying one is a better approach than another, just that you're coming in late on an issue that's been considered. My post is not about what the requirement ought to be; it's about how to document the requirement that is already there in the code. -- Dave Abrahams Boost Consulting www.boost-consulting.com