How future-safe is it to write a parser with Boost Spirit X3?

Question

I'm considering writing what is essentially my first parser since forever (= since the compiler class at Uni which I've forgotten mostly).

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.

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:

Where is boost-spirit 3? Is it abandoned?

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?

Dedie

Answer 1

It's already released, so there's little chance of it just vanishing.

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¹.

Here's a list of things that make me consider not using X3 in the following cases:

• 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:

• 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)

Note however, there are definite areas where X3 shines:

• 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?)

---

¹ see the mailing list, and e.g. x3 linker error with separate TU and linking errors while separate parser using boost spirit x3

² In fact, it might be "easy" to create one by creating a custom parser, building on with<> and any_parser<>

Hexyl

So, I +1 you for the detailed answer, but - doesn't your answer imply that it's going to stay the "less-used brother" of the mainline into the future as well? Or are they just working on improving the stiuation with stateful rules, independent lexer etc.? – Dedie

I merely confirm that it's officially experimental (unstable: the interface may change, there are warts). I have no claim about the future (I do not think it will remain less-used, that will probably depend on widespread adoption of c++14 only). They're working on the linking issues, but I'm not overly optimistic in that respect (TBF: I don't consider external linkage a requirement at all, but that's me). Lexer support is not gonna happen (me using my crystal ball) – Hexyl

Despite the previous comment saying "Lexer support is not gonna happen", Peter Huene implemented his own lexer support in a personal project here: github.com/peterhuene/puppetcpp/blob/master/lib/include/puppet/… – Veron