Larry Evans wrote:
On 04/26/2005 10:30 AM, Giovanni Piero Deretta wrote:
On 4/26/05, Larry Evans <cppljevans@cox-internet.com> wrote:
[snip]
Anyway, the get<type> form is most useful with tuples containing elements of different type. In practice you overload the meaning of the type to also be a an element tag. This way tuples become as
But isn't an enumerator in some enumeration the equivalent of an "element tag"?
powerful as structures: you can access element by "name". They are
The enumerator can also be thought of as a name.
more powerful actually, as they have introspection capability: elements can be enumerated. Also the possibility of accessing tuple elements indipendently of the exact tuple type and element position can be very handy in generic programming.
Which can be done with enumerators also.
The get<type> form that i proposed can be easily added with zero changes to the existing tuple code/interface. A more complex addition would allow the association of a tag to each tuple element i.e.: tuple<mpl::list<element1_type, element1_tag>, mpl::list<element2_type, element2_tag>,.....> a get<elementn_tag> would return the nth element. This would make the tag unique and maybe open new possibilities.
But again, I don't see why adding a tag is any better than using an enumerator. The only difference between an array (all elements of the same type) and a tuple, is that the type of the value as well as the value depends on the index. And if the types are indexed by the same enumeration, then you've solve the problem. In addition, a similar scheme can be used for variants (or disjoint sum). See
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/index...
BTW, tuples containing many objects of the same type are better seen as containers, thus the indexed get is fine.
Agreed, but the indexed get works just as well when the argument is an enumerator instead of a literal unsigned, and when it's an enumerator, the meaning is clearer:
t.get<0>(); t.get<1>();
is obviously not as clear as:
t.get<first_field>(); t.get<second_field>();
[snip]
In a theoretical extended_tuple, the enum could be part of the tuple itself, so you could do 'get<my_tuple.element1> (my_tuple)' and there would not be no name conflict. The problem with enums is that you have to maintain them separately: this is information duplication that could easily go out of sync.
Not if you use either something like mpl's map:
[...]
-------------------- cut here --------------------- or use a specialization of a template indexed by the enumeration, as shown in the boost-sandbox sum.cpp file mentioned above or in another test file, product.cpp, in the same location.
I'm not sure which is better.
Gentlemen, these are all variations of the associative tuple. An implementation of fusion's set and map will be available as soon as I formalize the interface. I already have an implementation handy, ready to be deployed. Yes, associative tuples are powerful structures. They could potentially simplify code such as those in phoenix lambda, let scopes and the named parameters. As to which is better: a (type) tag or an enumerator; a (type) tag is definitely better because 1) an enumerator fails to address common idioms like named parameters which uses type tags. And, 2) a type tag can handle enumerators as well if you place them in some sort of enum_<enum> template akin to mpl::int_: template <my_enum e> struct my_enum_ {}; IOTW, you can easily convert an enum to a type. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net