[boost] [Range] No Reply?

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-08 10:02:25

Thorsten Ottosen <nesotto_at_[hidden]> writes:

> Citat David Abrahams <dave_at_[hidden]>:
>
> 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