Re: [boost] Re: Small tuple extension

From: Giovanni P. Deretta (lordshoo_at_[hidden])
Date: 2005-04-27 10:45:30

Larry Evans wrote:
> On 04/26/2005 05:22 PM, Giovanni P. Deretta wrote:
> [snip]
> 
>>
>> As your code demonstrates, enumerators can be used without duplicating 
>> information, but an enum and map enum->type is required for each 
>> tuple. This is verbose and should be wrapped in a macro.  Then again, 
>> I don't 
> 
> 
> Agreed.
> 
>> like macros a lot :)
> 
> 
> But mpl and fusion are profuse with macros, or at least
> boost/preprocessor.
> 

Sure, I write macros myself, but i try to avoid them if i can.

>>
>> In the end,  getting 'by type' has the same expressive power of using 
>> enumerators, i simply think that it would have a better syntax and it 
>> would work out of the box with all tuples without the need of a map.
> 
> 
> But it wouldn't work for repeated types, unless, as you
> noted previously, some sort of "tag" were "associated" with
> the type, which is what an mpl::map does, only it assures there's
> only one type associated with each tag; whereas the example:
> 
>   tuple<mpl::list<element1_type, element1_tag>, mpl::list<element2_type,
>   element2_tag>,.....>
> 
> in one of your previous messages:
> 
>   http://article.gmane.org/gmane.comp.lib.boost.devel/122595
> 
> doesn't assure this, AFAICT.  Also, I'd think mpl::pair would be more
> succinct. 

Why not? You would get by 'tag' i.e. get<element1_tag>(tuple).
An extended_tuple<mpl::pair<type1, tag1>, mpl::pair<type2, tag2>...>; is 
almost exactly the same of a TR1 tuple<type1, type2 ...>; the extra tags 
are only used to accessing the tuple.  I think i failed to expain this, 
from your next example i think you thought that my extended_tuple where 
some sort of mpl-like container.
The extended_tuple probably requires modification to tuple code, so it 
is not really viable.
And yes, mpl::pair would be better, but i couldn't find it in the mpl 
documentation :)

>  So, the tuple version of the following:
>   struct employ
>   {  string name;
>      float salary;
>      int ssn;
>   };
> 
> could be:
> 
>   struct name{};
>   struct salary{};
>   struct ssn{};
> 
>   tuple
>   < mpl::pair<string,name>
>   , mpl::pair<float,salary>
>   , mpl::pair<int,ssn>
>   >::type;
> 
> which is not that much shorter than the enum_map_0 shown in my
> previous post:
> 
>   http://article.gmane.org/gmane.comp.lib.boost.devel/122661
> 
> After all, for each enum_map_0::f_i, for i=0..2, there's
> got to be a tag with your method:
> 
>   struct name{};
>   struct salary{};
>   struct ssn{};
> 
> and there's also got to be a pairing of tags to types, just as in
> the enum_map_0::field_map.
> 
> Am I missing something?
> 

Well, in my extended tuple example tags are _not_ associated with a 
tuple.  Different tuples can reuse the same tag set or part of it.
This is very useful for generic programming, for example, i may have a 
function that accept a tuple having a some_tag slot.  Doing this with 
enum is clumsy and not type safe.  I.e. a tuple might not map the whole 
enum set enum {a, b, c}, but get<a>(tuple_foo) would still compile even 
if 'a' is not logically part of tuple_foo. Also you are forced to use 
the enum ordering.  Anyway, i don't think you proposed to reuse the same 
enums, only the names, but then you are forced to write enums for every 
tuple.
Anyway, I think i will try fusion now :)

--
Giovanni P. Deretta