Re: [QI] Alternate parser not using boost::variant

In the unlikely case that anyone is interested in answer, I will answer my
own question but need to provide some background first.
I use spirit::qi as a "type-parser", so that I, given a type T can get the
parser for T by calling a parser-factory:
template<class T>
XXX get_parser<T>().

(It is a little bit more elaborate than that, but you get the idea).
Due to the difficulty of copying qi-parsers, I ended up returning a
boost::proto::terminal<rule&lt;Iterator,T()>, and using this approach and
defining the parser for a variant<T1,T2,...,TN> as get_parser<T1>() |
get_parser<T2>() | ... | get_parser<TN() and in that case my union parser
did not work. I did solve it eventually by specialise not_is_variant&lt;T>
and not_is_variant<T,qi::domain> as mpl::false_. I did have to define both
not_is_variant's;  defining one of them was not enough.
Fast forward to my last take of generating a parser-factory: get_parser now
returns a const reference to the rule which is a static variable. As a
result, I no longer have to specialize "not_is_variant" - it works right out
of the box.
The current status of my project is that my parser-factory seems to work out
of the box for tuples and almost out of the box for variants with the
exception that I may have to reorder individual choice-items in the parser
due to the greedy nature of qi. The order of elements in my variants is
significant and can not be changed.




--
View this message in context: http://boost.2283326.n4.nabble.com/QI-Alternate-parser-not-using-boost-variant-tp4687874p4688010.html
Sent from the spirit-general mailing list archive at Nabble.com.

------------------------------------------------------------------------------