|
Boost : |
From: Martin Bonner (Martin.Bonner_at_[hidden])
Date: 2007-07-10 10:17:49
From: Andrew Sutton
>
> 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.
Aahh. Light dawns.
> The idea of using functors is interesting... but for some reason, I'm
> having trouble seeing how the solution would work this morning.
That's because I was thinking of something like "copy from here to
there, optionally transforming the copied values", where a default of
template <class T> T& identity(T& x) { return x; }
would be fine (modulo dangling references).
I'm sure someone will be along shortly to show how to do it :-)
> I'll
> have to give it some thought. I think, however, that I'm doing
> something similar with my `not_given` type - it's being used as a
> sort of token that, when passed to template functions doesn't do
> anything.
-- Martin Bonner Project Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner_at_[hidden] www.pi-shurlok.com disclaimer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk