Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-15 08:15:50


It just occurred to me as I was writing the docs (it's amazing how
writing documentation clarifies design issues!) that for the
parameters library, "The Forwarding Problem" usually isn't really as
bad as it might seem. In a family of overloaded forwarding functions,
the only positions in which we need a T&/T const& overload pair are
those in which the corresponding parameter is an out (or in/out)
parameter. When passed non-positionally, the const/non-const issue is
handled by the overloaded operator= on the keyword objects.

So I'm thinking the macros for generating the overloads, in the next
release at least, should just take care of generating the right
overloads. For example, something like

  BOOST_NAMED_PARAMETER_FUNCTION(
    void, depth_first_search, (required(in))(in)(in)(out)(in) )

might work.

For reference, the docs for depth_first_search are at
http://www.boost.org/libs/graph/doc/depth_first_search.html

Here I am assuming that the parameter order would be:

     graph
     visitor
     index_map
     color_map
     root_vertex

[Doug, I am a little concerned about how to translatate the interface
for tutorial purposes, since the documented positional interfaces
don't include an overload that takes 5 parameters: index_map can only
be passed as a named parameter! I don't want to confuse people.
Could you take a look at libs/parameter/doc/html/index.html and give
your feedback? -- Thanks]

Of course, this idea doesn't work out so well for an unnamed
parameter interface, which we're also going to support after 1.33.
But that's a separate macro ;-)

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