views:

1026

answers:

5

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)?

+12  A: 

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.

Robert Gould
Thanks. I do have Boost dependencies already, but I'll go with named parameters instead.
Head Geek
A: 

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.

Paul Nathan
+2  A: 

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 ;) )

moogs
+4  A: 

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.
Ferruccio
By this same reasoning we should remove templates from C++ because they are complex and confusing. It's called "learning"
Raindog
Templates add a great deal of power to the language. I don't think you could say the same about named parameters. Just because something is complex, doesn't mean that it's useful.
Ferruccio
A: 

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.

Raindog