Boost Parameters library

Question

Recently I found Parameters library in the Boost. Honestly I didn't understand the reason why this is a part of Boost. When there is need to pass several parameters to the function you can make a structure from them, like:

struct Parameters
{
    Parameters() : strParam("DEFAULT"), intParam(0) {}
    string strParam;
    int intParam;
};

void foo(const Parameters & params)
{
}

Parameters params;
params.intParam = 42;
foo(params);

This is very easy to write and understand. Now example with using Boost Parameters:

BOOST_PARAMETER_NAME(param1) 
BOOST_PARAMETER_NAME(param2)

BOOST_PARAMETER_FUNCTION(
  (void),                // 1. parenthesized return type
  someCompexFunction,    // 2. name of the function template

  tag,                   // 3. namespace of tag types


  (optional              //    optional parameters, with defaults
    (param1,           *, 42)
    (param2,           *, std::string("default"))              )
  )
{
    std::cout << param1 << param2;
}

someCompexFunction(param1_=42);

I think it's really complex, and the benefit is not that significant..

But now I see that some of the Boost libraries (Asio) use this technique. Is it considered a best practice to use this library to pass many arguments?

Or maybe there are real benefits of using this library that I don't see? Would you recommend using this library in the project?

Only if you see features you don't want to implement. Most apps only need/want very simple command line switches. — Tom Kerr, Aug 17 '12 at 21:20
No, No, and No. If a best practice makes less readable code it's not a best practice, any benefit there might be is not worth the complexity, some parts of boost are indeed awesome but I would just use a struct for anything more than 3 or 4 parameters. — AJG85, Aug 17 '12 at 21:22
@TomKerr Well, personally I don't see much benefits or features I need. But maybe it will be really appreciated by the clients of my library? — nogard, Aug 17 '12 at 21:26
@nogard I understand your concern. I had case where I removed Boost.Parameter support from a function to increase compile times but people actually didn't like it, because specifying all the default becomes quite nasty. — pmr, Aug 17 '12 at 21:32

pmr · Accepted Answer · 2012-08-17T21:44:45.803

Your technique requires creating a lot of temporaries (given enough parameters) and will be rather verbose in some cases. Something that is even more tricky is documentation. If you go down the route of configuration structs, you will have two places where you need to explain your parameters. Documenting Boost.Parameter functions is easy in comparison.

It also keeps the verbosity down and allows me to reuse arguments for whole families of functions instead of composing a new configuration carrier over and over again.

If you don't like the library, don't use it. It has several other drawbacks you haven't mentioned (heavy includes, high compile times).

Also, why not just provide the best of two worlds? One function using Boost.Parameters and another using configuration structs, where both dispatch on a common implementation. Manage headers correctly and the "don't pay for what you don't use" promise will be kept. The price is maintainability. But you can always deprecate one interface if your users don't like it.

score 1 · Answer 2 · answered Aug 17 '12 at 21:25

Well, I don't use this library, but the key is that you can pass parameters by name.

Imagine that you have a function with a lot of parameters, and in most cases you only want to use a few. Maybe not always the same few, so putting these in front of the list (so the others can be supplied as defaults) won't help. That's where the "named parameter" stuff comes in: you just give the names and values of the parameters you want to pass, in any order you like, and the others will be defaulted. You don't even have to know all the possible parameters; a later version of the function can add new parameters without breaking anything (provided the defaults for the new parameters are chosen to mimic the old behavior).

In comparison to structures, you could make a structure and initialize everything with defaults. That's pretty much how this kind of stuff works internally anway, if I'm not mistaken, by passing a parameter object around and setting values there before passing it into the actual function at the end.

Seriously, and what is the problem of checking what are the parameters and supply them in correct form? I agree with one of the comments that some stuff in boost is awesome, but boost::parameter isn't one of them. Kurwa, the problem of customizing it etc etc, is far to big to be practical — There is nothing we can do, Jul 04 '15 at 18:11

Boost Parameters library

2 Answers2

Linked