Re: [boost] interest in 'tagged variant'? Useful in non-string spirit parsing.

From: Larry Evans (cppljevans_at_[hidden])
Date: 2007-12-20 12:18:12

On 12/17/07 16:29, Joel de Guzman wrote:
> Larry Evans wrote:
> 
>> 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?
> 
> Hi Larry, Pardon the delay in replying. Yeah, this makes
> perfect sense. Are there docs yet? Would you be interested in
> having it hosted in spirit2/support ?
> 

Yes, however, I'm still thinking.  One thing that bothered me
about using boost::variant was it had to be adapted to behave
like a tagged variant.  Wouldn't it be better to use a "bare-bones"
real tagged variant.  I'm assuming that then this could be adapted
to behave like the existing boost::variant.  Why?  Well, it seems
that boost::variant is a restriction on such a tagged variant
and a restriction is sorta like a derived class restricting
a super.  After all, a super cannot be converted to a derived,
but a derived can be converted to a super; therefore,
the derived is a more specific instance (i.e. a restriction)
of the super.

Anyhow, all this reasoning led me back to the aligned_types
mentioned in a May 07 post:

> http://archives.free.net.ph/message/20070514.193240.ada2f1bb.en.html

I've since been working on a non-variadic version of it,
which I just uploaded to vault:

http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=aligned_types.zip&directory=Data%20Structures&PHPSESSID=0998fe36863986f6bb6517b804771c4e

Of course this just defines the aligned_storage (and offsets, in case of 
tuples); however, it should be easy to create a tagged_variant
from aligned_types<composite_kinds::variant,Sequence>::type.