|
Boost : |
From: Larry Evans (cppljevans_at_[hidden])
Date: 2005-04-27 11:54:14
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk