标签: boost-parameter

我查看了Named Parameter Idiom和Boost :: Parameter库.每个人有什么优势？是否有充分的理由总是选择其中一个,或者在某些情况下每个人都可能比另一个好(如果是的话,在什么情况下)？

我经常使用Boost强类型def实用程序来提高程序的安全性.例如,通过编写如下代码:

BOOST_STRONG_TYPEDEF(int, X)
BOOST_STRONG_TYPEDEF(int, Y)
BOOST_STRONG_TYPEDEF(int, Width)
BOOST_STRONG_TYPEDEF(int, Height)

struct Rect {
    Rect(X x, Y y, Width w, Height h);
};

// Usage:
Rect rect(X(10), Y(20), Width(800), Height(600));

这里强大的typedef提高了代码的可读性和安全性.(如果参数以错误的顺序提供,编译器将报告错误,如果参数全部都不是这种情况int.)

我的问题是:

• 为此可以使用BOOST_STRONG_TYPEDEF吗？(文件非常简短.)
• 是否有重要的理由选择升压参数库？

我目前正在使用boost.parameter和一些工厂函数,编译时间越来越多.

目前我有一个像这样的共同模式:

auto thing = makeThing(property1 = foo::bar, "myThing"_thingName);

其中makeThing有30个参数,其中大部分都是默认值.我想保留"命名参数"语法以及按类型而不是按位置匹配参数的能力.

如何在不改变工厂调用站点的语法的情况下获得更好的编译速度？

注意:根据boost.MPL速度和强度速度之间的差异来判断,如果现代元编程技术用于boost.parameter等效,那么编译时应该至少有一个数量级的改进.

更新:这是我正在做的一个简略示例:在裸机嵌入式上下文中,我根据基于策略的类设计习惯用不同的外围设备抽象为复杂的模板类.每个类在编译时都会获取大量配置信息,并且只使用所需的功能(不能依赖优化器来去除未使用的东西,因为所有SFR交互都是可观察的,因此是不稳定的,因此不允许).

这些基于策略的类对于用户来说是非常丑陋的,并且如果大多数嵌入式用户在公共界面中看到<,那么我会使用boost.parameter创建一个性感的工厂,以便他们可以传递所有类型编码的愿望(像hana风格)我生成的类作为本地静态连接到所需的ISR并传回一个句柄.

namespace usb
{
    BOOST_PARAMETER_NAME(hw)
    BOOST_PARAMETER_NAME(vid)
    BOOST_PARAMETER_NAME(pid)
    BOOST_PARAMETER_NAME(device_class)
    BOOST_PARAMETER_NAME(max_packet_ep0)
    BOOST_PARAMETER_NAME(max_packet)
    BOOST_PARAMETER_NAME(packet_pool_size)
    BOOST_PARAMETER_NAME(device_description)
    BOOST_PARAMETER_NAME(device_calss_description)
    BOOST_PARAMETER_NAME(can_power_down)
    BOOST_PARAMETER_NAME(stall_supported)
    BOOST_PARAMETER_NAME(setup_packet_timeout)
    //...

BOOST_PARAMETER_FUNCTION(
    (usb_handle),
    make,    

    tag,                 

    (required(hw, *)) 

    (optional
    (vid, *, 0x6001_ci)
        (pid, *, 0x1234_ci)
        (device_class, *, cdc_class{})
        (max_packet_ep0, *, 8_ci)
        (max_packet, *, 64_ci)
        (packet_pool_size, *, 12_ci)
        (device_description, *, "")
        (device_calss_description, *, "")
        (can_power_down, *, 0_ci)
        (stall_supported, *, 0_ci)
        (setup_packet_timeout, *, 100_ci)
        )
)
{
    // makes a local …

我想使用 boost property_tree 解析以下 xml 结构。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Txn ver="1.0">
    <TOpts tCount="1"  tformat="0"  ttimeout="10" />
    <TData>
        <Tvalue date="YYMMDD" time="HHMM" Ref="100"/>
    </TData>
    <TCustOpts>
        <Param name="SALE" value="xyz" />
    </TCustOpts>
</Txn>

我能够解析Topts上述 xml 的第一个字段，但是对于TData&TCustOpts字段，我没有得到正确的迭代和方法来解析 xml 并面临异常。有人可以为我提供正确的TData&TCustOpts字段解析方法。下面是我的代码供参考。

stringstream ssString;
boost::property_tree::ptree pt1;
ssString << xml;
boost::property_tree::read_xml(ssString, pt1);

string TxnVer = pt1.get<string>("Txn.<xmlattr>.ver");

boost::property_tree::ptree formats = pt1.get_child("Txn");
BOOST_FOREACH(boost::property_tree::ptree::value_type const& node, formats) {
    if (node.first == "TOpts") {
        const boost::property_tree::ptree & attributes = node.second.get_child("<xmlattr>");
        BOOST_FOREACH(boost::property_tree::ptree::value_type const& …