[boost] Re: [Review] Named parameters library

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