Re: [boost] [parameter] Tutorial checked in

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-20 09:05:21

Rob Stewart <stewart_at_[hidden]> writes:

> From: David Abrahams <dave_at_[hidden]>
>> Rob Stewart <stewart_at_[hidden]> writes:
>> > I just took a look at> http://boost-consulting.com/boost/libs/parameter/doc/html/index.html> and I have a few comments.
>> Rob,
>> Thanks for your edits.  Most were excellent and I integrated themimmediately.
>
> I'm glad to help.
>
>>   Seeing the function described via table is harder to grasp.
>> I  suggest showing the function signature first, but omit the
>> defaults  for clarity.  That will provide parameter names, in
>> context, which  will make the connection to the table simpler.
>> 
>> I'm not sure what to do about that one.  The "function
>> signature" is afully general function template, with an
>> overload to handle mutablelvalues for the color_map.  If you
>> can suggest something that works,I'm open to it.
>
> I just looked at
> http://www.boost.org/libs/graph/doc/depth_first_search.html and
> didn't see a function like the one you're using.  However, I can
> guess at what it ought to look like from your table:
>
>    template <
>         class Graph
>       , class DFSVisitor
>       , class Root
>       , class ColorMap
>    >
>    void depth_first_search(Graph const & graph, DFSVisitor visitor,
>       Root root_vertex, IndexMap index_map, ColorMap & color);
>
> Whether any of the other types should use references to const I
> can't say.  Since color was described as an OUT parameter, I
> assumed that meant reference to non-const.

Yeah, that's about right.  No overload is needed -- I was just addled
when I wrote that.  The problem is, of course that while the signature
above is evocative, it is not the signature of any real function we'll
write.  I guess I could say, "here's what the signature might be if
all arguments were required..."  Make sense?

>> I don't know what to do about the hard-to-see vertical ellipsis.Maybe just use
>>       .      .      .
>> instead?
>
> You could use &#183; (a.k.a. &middot;), but the real issue is to
> trigger a much larger font size.

There *might* be something I could do about that.  I'll have to learn
a little something about css.

>> You asked:
>>    *Where is this assignment occurring?*
>> I tried to clarify:
>>   On the other hand, when passing arguments by keyword, the
>> keyword  object's assignment operator yields a temporary
>> |ArgumentPack|  object, and a conforming C++ compiler will
>> refuse to bind a  non-``const`` reference to a temporary.
>
> That does it.

Great.

>> You rewrote this section, and then also seemed confused about
>> what itmeans:
>>   a conforming C++ compiler will refuse to bind a non-``const``
>> reference to a temporary.  To support an interface in which the
>> last  argument is passed by keyword, there must be a
>> ``depth_first_search`` overload taking its argument by
>> ``const``  reference.
>> 
>> Here's your rewrite:
>>   a conforming C++ compiler will refuse to bind a non-``const``
>> reference to a temporary.  To support an interface in which the
>> last  parameter is an “out” parameter, and the
>> last argument is passed by  keyword, there must be a
>> ``depth_first_search`` overload taking its  other arguments by
>> ``const`` reference.
>> 
>> But your rewrite changes the meaning substantially.  Maybe you
>> couldtry to understand what I wrote or ask some more questions
>> before wetry to make it better?
>
> Well, I thought I understood what you were trying to say,
> obviously, or I wouldn't have attempted the rewrite.  So, let's
> see what your version is saying (to me).
>
> You say that there must be an "overloading taking its
> argument...."  Note the singular.  

Yes, note the singular!  Would it help if I wrote "taking that
argument" or "taking its final argument?"

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com