When is 1.33.0 going to be?
I think we're hoping to do a prerelease candidate this weekend or Monday.
rigth, so we can still change documents.
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.
ok.
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.
It's not like I don't agree, it's just that it is already said in the introduction.
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.
It's in the main cvs....how do I post a link to that? I usually keep a shortcut to the main cvs documentation.
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.
The sentence says that each type of iterator induces a type of range.
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),
that is not very elegant IMO.
especially not before they have been shown to be useful in specifying algorithms.
their usefulness should be evident from the fact that you can make code self-documenting. it is much more elegant to have a meanningful name of a template parameter than to call the parameter T and then specify in comments that T is so and so.
There's no need to build a parallel and redundant concept hierachy. In fact, it's probably harmful to do so.
how 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 cvs docs for the range library.
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?"
have you read the introduction *and* its example ???
Also, IIUC, this and other mentions of null terminated strings need to be removed now.
yes, when I get the time or when somebody volunteers (1.33 is out of the question). Anyway, once I can get a chance to update from the cvs, I can tweak the docs. (vs checkout: [15:53:38] waiting for agurtovoy's lock in /cvsroot/boost/boost/bo st/test/utils/iterator) I don't have the feeling that the range docs are totally inappropriate, they could probably be better, but I wonder if it is worth our effort to spend days on them; our time could probably be better spend. best regards -Thorsten