Re: [boost] [Boost.Parameter] questions and advice

From: David Abrahams (dave_at_[hidden])
Date: 2007-07-10 21:02:47

on Tue Jul 10 2007, Andrew Sutton <asutton-AT-cs.kent.edu> wrote:

>> I'm not clear what your "truly optional" parameters are actually  
>> for, but if (for example) they supply a functor could the default  
>> value be some sort of identity functor?
>
> I guess it might be worthwhile to distinguish formally between  
> optional parameters and those with default values. A parameter with  
> default values is still a required input to a function even if the  
> user doesn't explicitly pass a corresponding value. It's value is  
> supplied by the specification. An optional parameter is one affects  
> the function's behavior by its absence or presence in the argument list.
>
> There are actually a number of examples in Boost.Graph. Consider  
> dijkstra_shortest_paths(). There are two optional (output) parameters  
> that can be passed - a predecessor map that records the parents in  
> the shortest path tree and a distance map that records the distance  
> to each vertex. If they aren't supplied the algorithm doesn't do any  
> extra work. If one or both is supplied, the algorithm records parents  
> and/or distances. This isn't an extreme example of affected behavior,  
> but it is probably the most common.

In that particular case I would make the defaults for those parameters
be stubs that satisfy the syntactic concept requirements but on which
the "recording" operations compile away to nothing.  In general, I
would try hard to end up with one very generic algorithm operating
on parts that may or may not do anything.

In cases where it's impossible to share the same code without loss of
efficiency, I would use something like "tag dispatching" to choose among
different implementations.  It would be easy enough to dispatch on
boost::parameter::void_, for example.

HTH,

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com