Re: [boost] Re: Small tuple extension

From: Giovanni P. Deretta (lordshoo_at_[hidden])
Date: 2005-04-27 12:40:12

Larry Evans wrote:
> On 04/27/2005 11:16 AM, Giovanni P. Deretta wrote:
> 
>> ... replying to myself
>>
>> Giovanni P. Deretta wrote:
>>
>>> Larry Evans wrote:
>>>
>>>>
>>>> But it wouldn't work for repeated types, unless, as you
>>>> noted previously, some sort of "tag" were "associated" with
> 
> [snip]
> 
>> I couldn't parse this paragraph correctly the first time, the second 
>> time i *thought* i did get it. The third time i *did* get it, but i 
>> had already sent my reply... :)
> 
> 
> OK. Sorry for not being clearer :(  Other's in this list have stumbled
> over my wording also.
> 
>>
>>> 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.
>>
>>
>>
>> It was me that didn't understand. You are right, a map is better.
> 
> OK.
> 
>>
>>>
>>> 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.
> 
> 
> True, but that's not type safe.  For example:
> 
>   enum indices{i0,i1};
>   int ivec1[1];
>   int ivec2[2];
>   ivec2[i1];//OK
>   ivec1[i1];//BAD
> 
> Although c vectors are used, I think you can see the analogy.  the same
> "tag set" is used for both "tuple"'s ivec1 and ivec2; yet, one element
> of the tag set, i.e. i1, is not valid for the "tuple" ivec1.
> 
>>> 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 
> 
> 
> If you've defined the enum and map together, e.g. in the enum_map<i>
> structure, and used them together in enum_mapped, as shown here:
> 
> http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=cppljevans 
> 
> 
> in tuple_nested_enum_test.cpp, then 'a' (or 'f_0' in the vault file), is
> logically part of the tuple in the same way that 'a' is logically part
> of:
> 
>   struct abc
>   { int a; float b; char c;};
> 
> and the:
> 
>   tuple_mapped<enum_map<i> >::get<index>
> 
> for some i in 0..2, will only compile for some index in
> enum_map<i>::field_names, just as:
> 
>   abc::index
> 
> will only compile for some index in a,b,c.
> 
>>> 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.
> 
> 
> True, just as, for every c or c++ struct the programmer is forced to
> write names for every member variable.
> 
>>> Anyway, I think i will try fusion now :)
>>>
>> This still stand.
>>
> 
> I'd be curious to see how it turns out.
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>