Boost 是否因不像 Boost 那样感到内疚？答案

【问题标题】：Is Boost guilty of being un-Boost-like?Boost 是否因不像 Boost 那样感到内疚？
【发布时间】：2010-09-27 14:47:48
【问题描述】：

我刚刚阅读了 Boost::Spirit LL Parser 框架的介绍。前言暗示作者和创作者喜欢使用这种解析技术来读取程序选项。 Boost 没有自己的程序选项库吗？

我想知道，Boost 委员会是否会审查所有图书馆笔记的共同主题和风格？似乎每个图书馆的文档都有自己的风格。

对于一款令人惊叹的软件的小抱怨，我只是觉得它很好奇。

【问题讨论】：

标签： c++ boost parsing boost-spirit

【解决方案1】：

简单地说，Spirit 存在于 Boost.Program-Options 库之前。现在，我总是使用 Boost.Program-Options 而不是自己使用 Spirit 手动滚动。

【讨论】：

【解决方案2】：

你说得对，并不是所有的 boost 库都特别像 boost。 Spirit就是一个很好的例子。部分原因是当它被接受时，其他 boost 库还没有被接受/还没有足够成熟，Spirit 可以使用它们。（这就是为什么会有类似 3 个 Boost 库定义它们的自己的（不兼容的）占位符值 _1、_2 等的原因。

在大多数情况下，我相信他们正在逐渐努力将这些奇怪的东西重新组合在一起。但是，afaik，添加 Spirit 是因为它是如此巨大而令人印象深刻的东西，以至于它的“unboostness”被原谅了。 ;)

【讨论】：

【解决方案3】：

Spirit in Boost 可能有一天会成为 Boost in Spirit :-)

【讨论】：

【解决方案4】：

正如 Joel 所说，Spirit 诞生时我们没有 Program-Options。 Hartmut Kaiser 和我（都是 Spirit 开发人员）在工作中使用 Program-Options，而不是推出我们自己的 Spirit 解析器。 Program-Options 的功能远不止解析，而且，至少对于我们的需要，命令行解析的性能并不重要。对于性能关键解析，我肯定会使用 Spirit。

【讨论】：

【解决方案5】：

没有 Boost 风格委员会这样的东西。 ISO 的 WG21 将在通用样式上花费更多时间，但即使他们也设法忘记了 std::ifstream::ifstream((std::string const& filename)

【讨论】：