新标准的特性对 C++11 中的 boost 库实现是否有重大影响？答案

【问题标题】：Is there a significant impact of the new standard's features on the boost library implementation in C++11?新标准的特性对 C++11 中的 boost 库实现是否有重大影响？
【发布时间】：2013-04-19 06:54:02
【问题描述】：

新标准的特性对 C++11 中的 boost 库实现是否有重大影响？

鉴于存在可变参数模板，对库的boost::variant (BOOST_VARIANT_LIMIT_TYPES) 和boost::spirit 部分特别感兴趣。

有没有关于这方面的好文章？

【问题讨论】：

唯一的影响是一些东西可以从boost中删除（例如shared_ptr），以及实现
@BЈовић 我不认为这是准确的，boost::shared_ptr 仍然有更多功能，boost::regex 更多和不同的引导界面；此外，boost shared_ptr 与 PhoenixV2 的集成存在，但 std::[tr1::]shared_ptr 等不存在。
@BЈовић 这不是真的。使用 C++11，库的许多部分确实可以更容易实现，但可能不一定向后兼容 C++03 编译器。另一方面，有些部分需要改进，例如。支持仅移动类型。这对于变体来说尤其有趣 - 包含仅移动类型的变体应该在 C++11 中是可移动的。我知道 Boost.Optional 的一张票可以感知移动，所以他们似乎正在这样做:)
@Dukales Boost 专门设计为对 C++03 友好，因此大多数库默认情况下不使用 C++11 的“优点”。但是，例如，当您包含 fusion/adapted/std_tuple.hpp 时，Fusion 将使用可变参数 - 当您从 boost::tuple 切换时，您实际上会看到编译时间减少（但是，请参见上文：boost 元组具有（远）更多功能，并且不同的界面，所以不要认为它是替代品）
@ArneMertz 好点。我忘了搬家

标签： c++ boost c++11 boost-spirit boost-variant

【解决方案1】：

（我正在写我的第三条评论，专门针对 Spirit 的主题。我决定将我的 cmets 纳入答案）

Boost Spirit 将专门使用 C++11 功能（即放弃 C++03 支持），以便它可以充分利用改进的 TMP 功能并减少编译时间 - 编译时间是使用的一大缺点精神V2。

Spirit X3（实验性 V3 分支）已经在积极开发中：

还有其他新闻：Spirit V3 将仅支持 C++11 并支持移动：

Feb 11, 2013; 12:02pm, Joel de Guzman 写道：

不，X3 将仅是 C++11。纯的。没有变通办法。

请记住，尽管 X3 本质上是 X 实验性的。从 X3 到 final 会发生很多事情。我不会关闭 C++03 支持的大门，尽管我非常倾向于在没有 03 的情况下继续前进。无论如何，V2 不会很快消失。

此外，表达式模板将是auto-安全的，当您想要将“原始”解析器表达式绑定到局部变量时，不再需要 BOOST_SPIRIT_AUTO 宏。>

我找到了 Spirit X3 存储库的链接：

https://github.com/djowel/spirit_x3(github)

注意http://boost-spirit.com/home/2013/02/23/spirit-x3-on-github/的开发状态

【讨论】：

Spirit V3 will be C++11 only and move-enabled 听起来不错。这应该会导致编译时间的减少？
添加了指向 Spirit X3 存储库的链接
@Dukales 是的，这大大减少了编译时间（例如 - 浏览 SpiritX3：TOTAL：4.27 秒 vs. Spirit2：TOTAL：10.00 秒）
我认为更多的库应该采用这种“大胆”的方法，使用 C++11 特性可以减少代码、更易阅读和更短的编译时间。
@demorge 我同意，但我也很欣赏 Boost 需要保持庞大的用户群。从某种意义上说，Spirit 是一个异常值，因为它是高度具体的（对比，例如与 MPL），并且对编译器来说已经很重了，它基本上需要一个最新的编译器。这两个因素使得 Spirit 不会因采取这一举措而疏远其很多的用户群。此外，与 Spirit Classic 一样，出于兼容性目的，当前的 SpiritV2 将继续存在。