Re: [boost] Re: Small tuple extension

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2005-04-26 10:30:13

On 4/26/05, Larry Evans <cppljevans_at_[hidden]> wrote:
> On 04/26/2005 04:18 AM, Giovanni P. Deretta wrote:
> > Hi,
> >
> > I have been using a small extension to the tuple library 'get' function,
> > that I have found very handy.  It allows the extraction of an element of
> > a tuple by specifying its type instead of the index.
> > Example:
> >
> >     given the tuple boost::tuple<type1, type2, type3>
> >
> >     get<type1> returns the first element of the tuple of that type.
> >
> > This allows one to write more self describing code: you don't need to
> > look up the tuple element type when you find an indexed get function
> > buried deep inside some code.
> > This is especially useful with nested tuples where for example
> > looks more like line noise than real
> > code :).
> 
> Of course this wouldn't work for this tuple:
> 
>    tuple<type1, type1, type3>
> 

Well, get<type1>(my_tuple) would return the first element of that type
(actually my code will return the *last* element, but as I said, it
was just a quick hack).

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
powerful as structures: you can access element by  "name".  They are
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.

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.

BTW, tuples containing many objects of the same type are better seen
as containers, thus the indexed get is fine.
 
> Maybe if there were some way of associating an enumeration with the
> tuple, you could:
> 
>    get<f_i>(my_tuple)
> 
> where fi is some enumerator in, e.g.:
> 
>    enum my_tuple_fields
>    { f_0
>    , f_1
>    ...
>    , f_n
>    };
> 
> but even then, with nested tuples, there's a possible name conflict
> amoung the enumerators.  Possibly the enumerator names could contain
> a prefix indicating to which type they belong:
> 
>    enum type0_fields
>    { t0_f_0
>    , t0_f_1
>    ...
>    , t0_f_n0
>    };
> 
>    enum type1_fields
>    { t1_f_0
>    , t1_f_1
>    ...
>    , t1_f_n1
>    };
>

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.
 
--
Giovanni P. Deretta