Daniel James <daniel@calamity.org.uk> 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