Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> 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 · (a.k.a. ·), 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