Boost logo

Boost :

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):
> [snipped]
>
> 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
>>>quite large.
>> 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
> functions.

I don't see why not. What am I missing?
Anyway, it's surely possible to make a BOOST_NAMED_PARAMS_MEMBER_FUN
if neccessary.

> 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