From: Larry Evans (cppljevans_at_[hidden])
Date: 2007-12-09 14:14:21
On 12/06/07 11:26, Larry Evans wrote:
> On 12/05/07 21:23, Joel de Guzman wrote:
>> Larry Evans wrote:
>>> A prototype of such an extension is available in variant_tagged.zip
>>> Use of the variant_tagged could be used whenever non-string processing
>>> is required in a spirit parser.
>> There's definitely interest in Spirit :-)
>> Thanks for your work on this. Very useful.
> However, I've thought about it some more and I think maybe the
> original variant with fusion::pair's as the template arguments
> would work as well and would avoid the duplication of the
> tag (variant::which() and variant_taggged:tag()).
A new version has been uploaded to vault which uses fusion::pair.
To facilitate this, a new fusion/support/intkey_val_pair_map.hpp
file containing like-named template was created.
What's interesting about this is that it seems that if
instead of boost::variant, fusion::map were used with the
intkey_val_pair_map as arg(maybe mpl::unpacked), then you'd
have a tuple with possibly "named"(or enumed) instead of
less meaningful unsigned indexes (i.e. args to get<>).
OTOH, if, instead of fusion::pair, mpl::pair were used, and then
the intkey_...map passed to mpl::map, then you have the mpl
map with "named" indices.
I'm looking for a generalization that can simplify the coding
of all the classes by defining a minimum number of templates
that can be combined to get the most general results.
Does that make sense?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk