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