|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-07-22 17:07:46
Sorry it took me so long to reply. Among other things, I've been
sick.
Thorsten Ottosen <nesotto_at_[hidden]> writes:
> David Abrahams <dave <at> boost-consulting.com> writes:
>
>> > It's not like I don't agree, it's just that it is already said in the
>> > introduction.
>>
>> People will use this as reference docs. Don't expect them to read
>> cover-to-cover. They will jump to the concept definition, and that's
>> reasonable.
>
> right.
>
> so you propose an extra bullet like
>
> *Models*
>
> - all standard containers
> - std::pair<iterator,iterator> where iterator is an XXX iterator
> - builtin arrays
>
>
> for each concept?
Yes, that would be very helpful, but no, that's not what I'm asking
for. It's not enough. The concept definition that the
implementation relies upon is that
boost::begin(v)
is valid, etc., not that
begin(v)
is valid. If you tell people the requirement is the latter, and then
you tell them that standard containers are models of Range, they
say:
You're lying. There's no begin(v) for a std::vector v.
or they say:
Okay, there must be a begin(v) for a std::vector v, since you tell
me it's a model of the concept. I'll write an algorithm that
requires a Range argument, and then I'll use begin(v) on it. Works
great... until I pass a std::vector! Okay, that's broken, but
maybe I'll fix it by writing a begin overload in my own namespace.
Now begin(v) is valid... it still doesn't work! What is wrong?!
You snipped the following context
---- >>> 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. ---- > >> Go to the boost web page. Follow the link in the left column to CVS. >> There will be a link to CVSWeb. Browse. > > http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/range/doc/range.html I have looked at every instance of the word "begin" on that page and there is NOWHERE a description of a library-provided function called "begin." I am talking about an entry that tells you: - what header it appears in - what its effects are - what it returns - what it throws etc. Standard function documentation. I'm having a hard time believing that you really don't understand that this is required. You snipped the following context ---- >>>>> 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. >> >> It's still not a definition of anything. > > <g> > >> Please try not to make this >> so difficult for me. Going back and forth like this takes a lot of >> energy from both of us; we'd both be done sooner if you'd resist less >> (or if I just gave up). > > please just tell me how you would write it. I'll add your definition > to the docs. What you have now at http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/range/doc/range.html seems fine. >> >> 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? >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> So, what is the page really describing? Please just try to nail down >> in a few sentences, what you are trying to tell the user on this >> page. That will tell us what the right title is. > > It contains synopsis and from the synopsis you can jump to the > definition of the function/metafunction in question. > > maybe it should just be called Synopsis & Reference? Maybe. The change looks good. I think just "Reference" would be perfect actually. >> >> 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 ??? >> >> Do not expect users to read cover to cover. Introductory and tutorial >> material can be considered non-normative, and can leave out some >> details if absolutely necessary, but the concept definitions are part >> of the reference and the reference documentation needs to stand on its >> own. > > yeah. would the "models" bullet help? Yes, but as I described above, it's not enough. The reference needs a lot of work: > Overview > > Four types of objects are currently supported by the library: > > * standard-like containers > * std::pair<iterator,iterator> > * null terminated strings (this includes char[],wchar_t[], char*, and wchar_t*) > * built-in arrays You don't say what "supported" means. I assume you mean "can model Range." But what you've written leads me to conclude that if I write a model of Range, it will be unsupported. > Even though the behavior of the primary templates What "primary templates?" That term refers to a template definition that is not an explicit or partial specialization. > are exactly such that standard containers will be supported by > default, What does "by default" mean? > the requirements Of what? > are much lower than the standard container requirements. For > example, the utility class iterator_range implements the minimal > interface required to make the class Which class? [*I* can figure out what you mean, but the language here is confusing. Others will have a harder time] > a Forward Range. > > > Please also see Range concepts for more details. At this point, if I didn't already understand this library from its implementation, I would be lost, and a pointer to "Range concepts" sure wouldn't help. Gotta run now; I will try to comment on the rest of it soon. -- 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