On 12/06/07 11:26, Larry Evans wrote:
On 12/05/07 21:23, Joel de Guzman wrote:
Larry Evans wrote: [snip]
A prototype of such an extension is available in variant_tagged.zip here:
http://www.boost-consulting.com/vault/index.php?&directory=Data%20Structures
Use of the variant_tagged could be used whenever non-string processing is required in a spirit parser. [snip]
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?