Boost 是否因与 Boost 不同而感到内疚？
我刚刚阅读了 Boost::Spirit LL 解析器框架的介绍。 前言表明作者和创建者喜欢使用这种解析技术来读取程序选项。 Boost 没有自己的程序选项库吗？
我想知道，Boost 委员会是否会审查所有图书馆笔记的共同主题和风格？ 似乎每个图书馆的文档都有自己的风格。
对于一个令人惊叹的软件的小抱怨，我只是觉得它很好奇。
I was just reading the intro to the Boost::Spirit LL Parser framework. The preface suggests that the author and creator likes to use such parsing technology to read in program options. Doesn't Boost have its own library for program options?
I am wondering, does the Boost committee review all the library notes for common themes and style? It seems the doc for each library have their own flavor to them.
Small gripe for an otherwise amazing piece of software, I just found it curious.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
简而言之，Spirit 在 Boost.Program-Options 库之前就已存在。 现在，我总是使用 Boost.Program-Options，而不是使用 Spirit 手动滚动。
Simply, Spirit existed before the Boost.Program-Options library. Now, I always use Boost.Program-Options instead of hand-rolling my own using Spirit.
你是对的，并不是所有的 boost 库都特别像 boost。 精神就是一个很好的例子。 部分原因是，当它被接受时，其他 boost 库尚未被接受/足够成熟，无法让 Spirit 使用它们。 （这就是为什么有 3 个 Boost 库定义了它们自己的（不兼容的）占位符值 _1、_2 等）。
在大多数情况下，我相信他们正在逐渐努力将这些奇怪的东西重新合并在一起。 但据我所知，添加“精神”是因为它是如此巨大且令人印象深刻，以至于它的“无助推力”被原谅了。 ;)
You're right, not all boost libraries are particularly boost-like. Spirit is a very good example of this. Part of the reason is that when it was accepted, other boost libraries were not yet accepted/sufficiently mature for Spirit to use them. (That's why there are something like 3 Boost libraries that define their own (incompatible) placeholder values _1, _2 and so on).
In most of these cases, I believe they're gradually working on getting these oddities merged back together. But afaik, Spirit was added because it was such a big and impressive thing, that it's "unboostness" was forgiven. ;)
Boost 中的精神可能有一天会成为精神中的 Boost :-)
Spirit in Boost may one day be Boost in spirit :-)
正如乔尔所说，当 Spirit 诞生时，我们还没有程序选项。 Hartmut Kaiser 和我（都是 Spirit 开发人员）在工作中使用程序选项，而不是推出我们自己的 Spirit 解析器。 Program-Options 所做的不仅仅是解析，而且，至少对于我们的需求来说，命令行解析的性能并不重要。 对于性能关键的解析，我肯定会使用 Spirit。
As Joel said, we didn't have Program-Options when Spirit was born. Hartmut Kaiser and I (both Spirit developers) use Program-Options at work, instead of rolling out our own Spirit parser. Program-Options does a lot more than parsing, and, at least for our needs, the performance of our command line parsing isn't important. For performance critical parsing, I'd definitely use Spirit.
不存在 Boost 风格委员会这样的东西。 ISO 的 WG21 将在通用样式上花费更多时间，但即使他们也设法忘记了 std::ifstream::ifstream((std::string const& filename)
There's no such thing as a Boost style committee. ISO's WG21 will spend a bit more time on common style, but even they managed to forget std::ifstream::ifstream((std::string const& filename)