From: David Abrahams (dave_at_[hidden])
Date: 2004-11-13 17:50:16
Daniel James <daniel_at_[hidden]> writes:
> David Abrahams wrote:
>> This approach is superior to bgl_named_params in part because it
>> avoids undue coupling and dependency in a library design. That
>> coupling is discussed in depth in this excerpt from C++ Template
>> Metaprogramming (http://www.boost-consulting.com/mplbook):
> This coupling could be avoided by using an overloaded operator to
> combine the arguments, for example:
> f(slew(.799) | name("z"));
> An advantage of this method is that it avoids the need for the
> forwarding functions.
You could also write
(slew = .799) | (name = "z")
But the disadvantage of these schemes is that you lose the positional
interface to f. Now you're forced to use named parameters.
>>>However, the amount of work needed to code parameters for this is
>> Really? Did you compare how much work it would be to use
>> BOOST_NAMED_PARAMS_FUN vs. what you're suggesting below?
> Unless I'm mistaken, BOOST_NAMED_PARAMS_FUN can't be used for member
I don't see why not. What am I missing?
Anyway, it's surely possible to make a BOOST_NAMED_PARAMS_MEMBER_FUN
> It also doesn't allow exception specifications for free
> functions, although I'm not sure if that's much of a loss.
No, I don't think it is much of a loss.
-- Dave Abrahams Boost Consulting http://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