Thorsten Ottosen <nesotto@cs.aau.dk> writes:
Citat David Abrahams <dave@boost-consulting.com>:
Hi Dave,
Thorsten,
there are important issues here that go to the suitability of this library for generic programming. I notice there was no answer on the list. It's crucial that you deal with these questions eventually, and IMO it should happen before the 1.33.0 release.
I'll see what I can do. My laptop was stolen two weeks ago, so its hard for me to do any real work.
Ouch! I'm sorry to hear that!
When is 1.33.0 going to be?
I think we're hoping to do a prerelease candidate this weekend or Monday.
Anyway, here's the issues:
I'm not sure that you quite "got" most of the concerns I raised.
1. change XXX to boost::XXX. ok, I don't see any problem with this. I could fix it monday.
-------------- If you already understood everything I'm writing in this section delimited by dashes, please just tell me so and I'll relax. I'm not asking for you to simply change XXX to boost::XXX everywhere. To quote from my original posting:
| 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)
The problem is that the Range concept requirements, as you specified them, are not satisfied by standard containers. Therefore the standard containers are not Ranges. Since it is a goal of the library that the standard containers be Ranges, you need to fix the way you've specified the concept requirements. And as I said later in the post:
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.
-------------- I also said:
| 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.
And then I asked that you post a link (both to the page with the boost::begin documentation and to the page in the main docs that links to it), but I have yet to see a reply.
2. swappable range:
The page says: "Since ranges are characterized by a specific underlying iterator type, we get a type of range for each type of iterator."
that's the definition.
Sorry, but that's not a definition of anything.
Is it so hard to grasp?
It is easy to infer what you mean, if you're very familiar with the new iterator concepts. It's also very easy to misinterpret if you're not, because swappable iterator is a counterintuitive name. More importantly, as I suggested, there is no need to name these concepts (because you can just say "Requires: iterator<R>::type is a model of RandomAccessTraversalIterator," or whatever), especially not before they have been shown to be useful in specifying algorithms. There's no need to build a parallel and redundant concept hierachy. In fact, it's probably harmful to do so.
3. Implementation of concepts.
A type conforms to a concept, so ok, you can't implement it. Maybe a renaming to "Implementations of types that concorm to Range concepts". ?
I don't know what the right title is first try to answer the question I asked: You need to rename this page. What is it really describing? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4. links from concepts to implementation.
I'm not sure what you're referring to.
I remember I put some links when you asked for it. It should be in the cvs code.
In the code? I remember asking you to post some links. Or maybe you mean you fulfilled the request in (**) to put links in the documentation? Can you tell me where, on the boost-consulting CVS mirror, I can find that?
Do you want more links?
I can't know until I can see what you've already done.
5. containers and iterators. It should be explained in the introduction that pairs and containers "just works".
That is insufficient. The concept requirements have to be correct. And by the way, if you mean "This library therefore provides the means to adapt standard-like containers, null terminated strings, std::pairs of iterators, and raw arrays (and more), such that the same generic code can work with them all." then no, it doesn't make it clear that they "just work." It claims that the library gives me the *means* to make them "just work." So I'm left asking, "how do I do that?" Also, IIUC, this and other mentions of null terminated strings need to be removed now. -- Dave Abrahams Boost Consulting www.boost-consulting.com