Feb 23

Oh, in case anyone wants to follow the development of X3, here are the Github links:


The full attribute mechanism works + basic C++lambda support. I’ve ported one example (calc4.cpp) which parses to an AST. The AST remains the same. Only the way the grammars are written had to change.

For a teaser: here’s GCC times:

SpiritX3: TOTAL :   4.27 secs
Spirit2:  TOTAL :  10.00 secs

Even faster at CT than the first Spirit3 attempt. Runtime speed? I expect it to be faster than Spirit-2. The rules have changed (pun intentional). Now, there’s no longer the need for virtual functions and auto is used extensively. I expect code size to be smaller too because the compiler can generate more efficient code.

Here’s the calculator grammar (based on calc3.cpp):

//  The calculator grammar
namespace calculator_grammar
    using x3::uint_;
    using x3::char_;

    x3::rule<class expression, ast::program> const expression;
    x3::rule<class term, ast::program> const term;
    x3::rule<class factor, ast::operand> const factor;

    auto const expression_def =
        >> *(   (char_('+') >> term)
            |   (char_('-') >> term)

    auto const term_def =
        >> *(   (char_('*') >> factor)
            |   (char_('/') >> factor)

    auto const factor_def =
        |   '(' >> expression >> ')'
        |   (char_('-') >> factor)
        |   (char_('+') >> factor)

    auto const calculator = x3::grammar(
            expression = expression_def,
            term = term_def,
            factor = factor_def

using calculator_grammar::calculator;

7 Responses to “Spirit X3 on Github”

  1. Jason Switzer says:

    Is Spirit X3’s switching to lambdas or autos going to help reduce template error spew?

    • Joel de Guzman says:

      Yes. But that’s not the only way to tackle the problem. The most useful strategy was by simplifying as much template metaprogramming as possible.

  2. karsten says:

    What does

    x3::rule const expression;

    do? I have not seen that syntax before.

  3. Michel Lesoinne says:

    I have downloaded Spirit X3 and find one issue with the rule design: they may not work correctly if a rule recursion involves a change in context within the recursion because all rules will use the first context. Imagine for example a recursion that changes somewhere the Skip Parser context component, such a change would get ignored within the next recursive call to the rule.
    I have created my own parser based on some of your ideas, but to address this particular issue, I have decided to add some variadic template parameters to the rule to specify which of the context characteristics can affect the rule. This approach has in my opinion two benefits: It solves the issue I mentioned above and it renders explicit the assumptions of possible dependencies on the context, thus leading to cleaner code.
    The issue I mentioned gets solved by my approach because when a skip parser is changed, the context that was created with the previous skip parser does not match the correct signature anymore.
    I can share my code if you or others are interested.

    • Joel de Guzman says:

      Michel, I’d need to know more. You can catch us at IRC ##spirit channel. Look for djowel and lets discuss. Ping me there.

Leave a Reply

preload preload preload