blocks|key|4442974|text|简单地说，精神早于Boost.Program-Options库就存在了。现在，我总是使用Boost.Program-Options，而不是使用Spirit手动滚动自己的选项。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4442975|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Simply, Spirit existed before the Boost.Program-Options library. Now, I always use Boost.Program-Options instead of hand-rolling my own using Spirit.

blocks|key|4442900|text|你说得对，并不是所有的boost库都特别像boost。Spirit就是一个很好的例子。部分原因是当它被接受时，其他boost库还没有被接受/还没有足够成熟的精神来使用它们。(这就是为什么有类似3个Boost库的原因，它们定义了自己的(不兼容的)占位符值_1、_2等等)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4442901|在大多数情况下，我相信他们正在逐步努力将这些奇怪的东西重新合并在一起。但是afaik，精神是添加的，因为它是一个如此大和令人印象深刻的东西，它的“不启动”是可以原谅的。;)|4442902|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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. ;)

blocks|key|2975396|text|提升中的精神可能有一天会在精神上得到提升:-)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2975397|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Spirit in Boost may one day be Boost in spirit :-)

blocks|key|4443000|text|正如Joel所说，当“精神”诞生时，我们还没有计划选项。Hartmut+Kaiser和我(都是精神开发者)在工作中使用程序选项，而不是推出我们自己的精神解析器。Program-Options做的不仅仅是解析，至少对于我们的需求来说，命令行解析的性能并不重要。对于性能关键的解析，我肯定会使用Spirit。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4443001|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|660657|text|没有Boost风格委员会这回事。国际标准化组织的WG21会花更多的时间在通用样式上，但即使是他们也设法忘记了std::ifstream::ifstream((std::string+const&+filename)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|660658|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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&amp; filename)

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.

Is Boost guilty of being un-Boost-like?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我刚刚在读Boost::Spirit LL解析器框架的简介。前言表明作者和创建者喜欢使用这种解析技术来读取程序选项。Boost不是有自己的程序选项库吗？我想知道，Boost委员会是否审查了所有图书馆笔记的共同主题和风格？似乎每个库的文档都有自己的风格。对一个令人惊叹的软件的小小抱怨，我只是觉得很好奇。

问Boost是不是因为不支持Boost而感到内疚？
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Boost是不是因为不支持Boost而感到内疚？EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Boost是不是因为不支持Boost而感到内疚？
EN