最近我发现Parameters Boost 中的库。老实说,我不明白为什么这是 Boost 的一部分。当需要将多个参数传递给函数时,您可以从中创建一个结构,例如:
struct Parameters
{
Parameters() : strParam("DEFAULT"), intParam(0) {}
string strParam;
int intParam;
};
void foo(const Parameters & params)
{
}
Parameters params;
params.intParam = 42;
foo(params);
这很容易写和理解。 现在以使用 Boost 参数为例:
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);
我认为它真的很复杂,而且好处并不那么显着..
但现在我看到一些 Boost 库 (Asio) 使用了这种技术。 使用此库传递许多参数是否被认为是最佳实践?
或者也许使用这个库有我看不到的真正好处? 您会推荐在项目中使用这个库吗?
最佳答案
您的技术需要创建大量临时对象(如果足够 参数),并且在某些情况下会相当冗长。一些东西 更棘手的是文档。如果你走这条路 配置结构,你将有两个地方需要 解释你的参数。记录 Boost.Parameter 函数很容易 相比之下。
它还降低了冗长程度,并允许我重用参数 整个功能系列而不是组成一个新的配置 载体一遍又一遍。
如果您不喜欢该库,请不要使用它。它还有其他几个 您没有提到的缺点(大量包含,高编译时间)。
此外,为什么不提供两个世界中最好的呢?一个函数使用 Boost.Parameters,另一个函数使用配置结构,两者都在一个共同的实现上分派(dispatch)。正确管理 header ,“不为不使用的东西付费”的 promise 将得到遵守。代价是可维护性。但是,如果您的用户不喜欢某个界面,您始终可以弃用它。
关于c++ - boost 参数库,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12013273/