升压参数库 [英] Boost Parameters library

问题描述

最近我发现参数 Boost中的库.老实说，我不明白为什么这是Boost的一部分.当需要将几个参数传递给函数时，可以从中构造一个结构，例如:

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

这很容易编写和理解. 现在使用Boost参数的示例:

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..

但是现在我看到一些Boost库(Asio)使用了这种技术. 使用此库传递许多参数是否被视为最佳实践?

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?

推荐答案

您的技术需要创建大量临时工(足够多) 参数)，并且在某些情况下会很冗长.一些东西 文档更加棘手.如果你走的路线 配置结构，您将需要在两个地方 解释您的参数.记录Boost.Parameter函数很容易 比较起来.

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

此外，为什么不仅仅提供两个世界中最好的呢?一个函数使用Boost.Parameters，另一个函数使用配置结构，这两个函数都在一个通用实现上分派.正确管理标头，将保留不为不使用的产品付费"的承诺.价格是可维护性.但是，如果您的用户不喜欢它，您总是可以弃用一个界面.

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.

这篇关于升压参数库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！