用Boost Spirit X3编写解析器对未来有多安全? [英] How future-safe is it to write a parser with Boost Spirit X3?
问题描述
我正在考虑永远写本质上是我的第一个解析器(=自从我最忘记的Uni编译器类以来).
I'm considering writing what is essentially my first parser since forever (= since the compiler class at Uni which I've forgotten mostly).
自从我使用C ++以来，我一直在考虑使用Boost Spirit.然后我注意到有一个常规" 2.5.2，还有一个名为Spirit X3的代码的神奇子集.
Since I use C++, I was thinking of using Boost Spirit. Then I noticed there's the "regular" 2.5.2 and there's something magical subset of the code named Spirit X3.
我还注意到，Boost Spirit X3已于2年前宣布/讨论/预发布，但Boost Spirit的正式版本是2.5.2.最后，我读到:
I' also ve noticed that Boost Spirit X3 was announced/discussed/pre-released already 2 years ago, yet Boost Spirit's official version is 2.5.2. Finally, I read:
因此，我知道"这不是一个废弃的项目-而是一个非常积极维护的项目.用Spirit X3编写解析器对我来说有多安全"?它是否有可能失败/被丢弃/被抛弃，或者确定会成为Boost Spirit发布的主线?
So I "know" that it's not an abandoned project - but not a very actively maintained project. How "safe" is it for me to write a parser with Spirit X3? Is it possible it might fail / be dropped / be abandoned, or is it certain to become the main line of Boost Spirit release?
推荐答案
它已经发布，因此几乎没有消失的可能性.
It's already released, so there's little chance of it just vanishing.
即使在生产代码中，我也自由使用X3:毕竟，我们确实有测试是有原因的.
I liberally use X3 even in production code: After all, we do have tests for a reason.
也就是说，我知道散布在各个翻译部门的规则的链接周围存在许多麻烦的问题.
That said, I know a number of hairy issues surround the linking of rules spread across separate translation units¹.
以下是在以下情况下让我考虑不使用X3的事情的列表:
Here's a list of things that make me consider not using X3 in the following cases:
-
Qi的属性转换逻辑更具吸引力(使规则更具可读性).参见例如
- 需要集成Phoenix Boost Spirit X3无法编译具有可变因子的重复指令
- 需要在各个TU之间共享规则
- where Qi's attribute transformation logic is more enticing (makes for more readable rules). See e.g.
- Phoenix integration is desired Boost Spirit X3 cannot compile repeat directive with variable factor
- Sharing rules across TUs is desired
在以下情况下紧迫的差异较小:
Slightly less pressing differences are when:
-
涉及到
- 本地人( "X3变成了真正的乏味，(如果不是完全无法忍受的话)有状态规则(我指的是带有本地人"的规则)" ).使用
with<>可以解决很多问题: Boost Spirit X3无法编译具有可变因子的重复指令，但我不认为它是可重入的 - 需要懒惰的规则调用²
- 需要使用Lexer(除非重写，否则我不会将Qi/Lex语法移植到X3)
- locals are involved ("X3 becomes a real tedium, (if not completely unbearable) with stateful rules (by which I mean rules with "locals")"). A lot of it can be solved using
with<>: Boost Spirit X3 cannot compile repeat directive with variable factor but I'm not convinced it's re-entrant - lazy rule invocation is required²
- Lexer is desired (i.e. I wouldn't port a Qi/Lex grammar to X3, except by rewrite)
但是请注意，X3在某些地方会发光:
Note however, there are definite areas where X3 shines:
- 编译时间
- 易于生成动态规则/自定义指令(请参见 boost :: spirit :: x3属性兼容性规则，直觉或代码?或 Spirit-Qi:如何编写非终端解析器?)
- compilation time
- ease of generating dynamic rules/custom directives (see boost::spirit::x3 attribute compatibility rules, intuition or code? or Recursive x3 parser with results passing around)
- ease of creating custom parsers (e.g. Spirit-Qi: How can I write a nonterminal parser?)
¹查看邮件列表，例如带有单独的TU的x3链接器错误和
¹ see the mailing list, and e.g. x3 linker error with separate TU and linking errors while separate parser using boost spirit x3
²实际上，通过创建基于with<>和any_parser<>
² In fact, it might be "easy" to create one by creating a custom parser, building on with<> and any_parser<>
这篇关于用Boost Spirit X3编写解析器对未来有多安全?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
