Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-07-13 10:54:41


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk