Re: Design/structure X3 parser more like Qi parser

Hi!

We have a fairly large parser with c-like expression handling, configuration files and source files. We made a library with a Parser class that have a few methods that are called, depending on grammar, and an ast.h for all the types of the resulting trees. Also error handling type leaks and bit, etc. Not a whole lot of other stuff is part of the interface, but some visibility leakage.

When it comes to encapsulation and initialization, everything is in a parser namespace of course, and we're using the standard .h/.cpp/_def.h setup per grammar, which are called from the parser class's methods.

As I'm parsing tokens, where I use global variables for the tokens I compare with, I needed to have them all constructed before the rules that capture and compare with them are initialized. Which is easy when you have just one file, you just defined the tokens up top. Not so easy when you have multiple files that want to use the same tokens. My solution is to have them a the top of one file, and have all other files use rules which initialize from functions, by not using the standard macro. See earlier post on the list (search for "Fixes for BOOST_SPIRIT_DEFINE", or check link below).

https://sourceforge.net/p/spirit/mailman/message/34947312/

Barring some linking issues and such, it's working fine for us.

  /Mikael

From: Sandro Pirkwieser [mailto:[email protected]]
Sent: Friday, December 2, 2016 12:33
To: [email protected]
Subject: [Spirit-general] Design/structure X3 parser more like Qi parser

Hi,

so far we used Spirit Qi for our parsers. Mainly due to large compilation times we were eager to experiment with X3.
It seems that there are two ways of designing a parser: (1) make the whole parser static, or (2) embed it in a function/method.
The disadvantages of (1) are that one always has to pay the costs of initializing the static parser, and the rather loose encapsulation in a namespace.
In case of (2) the parser is created each time (though it might be saved/cached), code reuse is more difficult (only the "main rule"), and only simple parsers are possible (without circular references).
When dealing with larger and complex parsers, these things matter. Having the parser encapsulated in a class would solve these issues, as was the case for Qi.
Unfortunately we were not able to do this with X3, as on the one hand 'auto' cannot be used for members (and stating the actual type would be unhandy), and on the other hand when having the rule and the definition separated the linking via BOOST_SPIRIT_DEFINE does not seem to work in this context.

We found the recommendation regarding the xxx.hpp, xxx.cpp and xxx_def.hpp structure by Joel, but is it possible to structure/design an X3 parser having the above issues in mind?
What are your experiences with X3 when it comes to designing/structuring larger, complex parsers?

Best regards,
Sandro

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general