C++ “Named Parameter Idiom” vs. Boost::Parameter library

Question

I've looked at both the Named Parameter Idiom and the Boost::Parameter library. What advantages does each one have over the other? Is there a good reason to always choose one over the other, or might each of them be better than the other in some situations (and if so, what situations)?

Answer 1

Implementing the Named Parameter Idiom is really easy, almost about as easy as using Boost::Parameter, so it kind of boils down to one main point.

-Do you already have boost dependencies? If you don't, Boost::parameter isn't special enough to merit adding the dependency.

Personally I've never seen Boost::parameter in production code, 100% of the time its been a custom implementation of Named Parameters, but that's not necessarily a good thing.

Answer 2

Normally, I'm a big fan of Boost, but I wouldn't use the Boost.Parameter library for a couple of reasons:

1. If you don't know what's going on, the call looks like you're assigning a value to a variable in the scope on the calling function before making the call. That can be very confusing.
2. There is too much boilerplate code necessary to set it up in the first place.

Answer 3

Another point, while I have never used Named Parameter Idiom, I have used Boost Parameter for defining up to 20 optional arguments. And, my compile times are insane. What used to take a couple seconds, now takes 30sec. This adds up if you have a library of stuff that use your one little application that you wrote using boost parameter. Of course, I might be implementing it wrongly, but I hope this changes, because other than that, i really like it.

Answer 4

The Named Parameter idiom is a LOT simpler. I can't see (right now) why we would need the complexity of the Boost::Parameter library. (Even the supposed "feature" Deduced parameters, seems like a way to introduce coding errors ;) )

Answer 5

You probably don't want Boost.Parameter for general application logic so much as you would want it for library code that you are developing where it can be quite a time saver for clients of the library.

Answer 6

Never heard of either, but reviewing the links, named parameter is WAY easier and more obvious to understand. I'd pick it in a heartbeat over the boost implementation.