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 t

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