35

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

manlio
  • 18,345
  • 14
  • 76
  • 126
Head Geek
  • 38,128
  • 22
  • 77
  • 87
  • 1
    I had no idea about both of them. Just gone though both of them. Thanks Geek – TG. Oct 15 '08 at 15:14
  • Not enough for the answer: a code using `Boost::Parameter` always embeds an implicit untestable transformation, +1 to the named parameter idiom – bobah Feb 12 '14 at 18:58
  • 1
    Can anyone add a link to a working "named parameter idiom" page? – xaxxon Dec 03 '15 at 00:55
  • 1
    Working link for [Named Parameter Idiom](https://isocpp.org/wiki/faq/ctors#named-parameter-idiom) – Sam Mar 28 '17 at 15:18

6 Answers6

19

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
  • 68,773
  • 61
  • 187
  • 272
16

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
  • 98,941
  • 38
  • 226
  • 299
  • 4
    By this same reasoning we should remove templates from C++ because they are complex and confusing. It's called "learning" – Raindog Oct 21 '08 at 22:45
  • 15
    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 Oct 24 '08 at 01:10
9

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.

sdf
  • 91
  • 1
  • 1
2

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
  • 8,122
  • 8
  • 44
  • 60
2

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
  • 1,468
  • 3
  • 14
  • 28
0

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
  • 39,638
  • 28
  • 112
  • 212