Re: [Boost-users] [tuple] no easy access to get function
----- Mensaje original ----- De: François Duranleau <duranlef@iro.umontreal.ca> Fecha: Domingo, Enero 22, 2006 6:08 am Asunto: Re: [Boost-users] [tuple] no easy access to get function
On Sat, 21 Jan 2006, JOAQUIN LOPEZ MU?Z wrote:
----- Mensaje original ----- De: Frank Birbacher <bloodymir.crap@gmx.net> Fecha: Sábado, Enero 21, 2006 2:29 am Asunto: [Boost-users] [tuple] no easy access to get function
Today I wanted to std::transform a range of tuples into a sequence of one element. I thought I could just take the address of some tuple::get<N> function. Maybe also specify the Tuple type as template>> parameter [...] I'd rather want to take the address of boost::tuple::get<N,Tuple>, but the template parameters won't match.
Maybe you forgot the final s in "tuples" when writing
boost::tuples::get<N,Tuple>
There is a thin wrapper declared in the boost namespace as well. The probleme is elsewhere. The argument to the get function is not a boost::tuple<>, but some base class template. Thus the template arguments of the function are not and an integer and a tuple, but an integer and something else (actually, a cons<HT,TT> if you look in the code). To take the address of such a function, you need to bind the integer, as well as HT and TT, not a tuple.
Yep, I see. You're right. Well, you can refer to get<> as follows boost::tuples::get<N,typename Tuple::inherited> Note that this is not relying on undocumented implementation, so called "const lists" are explained and made public at http://boost.org/libs/tuple/doc/tuple_advanced_interface.html So I'd say you can use the former reference to get safely.
However, I am wondering if there would be a problem to declare the thin wrapper simply like this (example with the const version):
template< int N , typename Tuple > inline typename tuples::access_traits< typename tuples::element< N , Tuples >::type >::const_type get( const Tuple& t ) { return tuples::get< N >( c ) ; }
?
That would also work, but my proposal above is simpler. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Sun, 22 Jan 2006, JOAQUIN LOPEZ MU?Z wrote:
Yep, I see. You're right. Well, you can refer to get<> as follows
boost::tuples::get<N,typename Tuple::inherited>
Note that this is not relying on undocumented implementation, so called "const lists" are explained and made public at
http://boost.org/libs/tuple/doc/tuple_advanced_interface.html
So I'd say you can use the former reference to get safely.
That doesn't work. boost::tuples::get has 3 template arguments, not 2. You need to do this: boost::tuples::get< N , typename Tuple::head_type , typename Tuple::tail_type > As a matter of fact, you can drop the 'tuples::' as well. Even then, a problem remains (and the approach I suggested doesn't solve that either): the overload of the function on the constness of the parameter. So you have to explicitly cast the function or make a wrapper. -- François Duranleau LIGUM, Université de Montréal "Ne me demandez pas comment ça va, car je vous mentirai." - moi-même _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi! François Duranleau wrote:
boost::tuples::get< N , typename Tuple::head_type , typename Tuple::tail_type >
As a matter of fact, you can drop the 'tuples::' as well. Even then, a problem remains (and the approach I suggested doesn't solve that either): the overload of the function on the constness of the parameter. So you have to explicitly cast the function or make a wrapper.
Writing a cast or specifying all template parameters is way too much noise in a std::transform call. So I will stick with my wrapper until the tuples library catches up on this issue. Thanks for info to all! Frank
participants (1)
-
Frank Birbacher -
François Duranleau -
JOAQUIN LOPEZ MU?Z