Re: Defect Report: tuple::tail() should be in the public interface
In article <46517ea1$0$15148$4c368faf@roadrunner.com>, Joe Gottman
<jgottman@carolina.rr.com> wrote:
\
A general approach is to construct an mpl sequence from tuple_size<> and
tuple_element<> and creating a boost::variant from that sequence. You
could convert the tuple to an stl::container of the variant type and
just use ordinary algorithms, providing a functor that handles all types
passed. or just do above and pass get<N>(t) to the functor/function
like above.
I agree that this is will work, but this is a heck of a lot of
machinery to require just to print out a tuple. Also, it is not
reusable, so clients would have to repeat the pattern to do something
else with the entire tuple. And as for copying, in every implementation
of tuple I have seen a tuple<X, Y, Z> contains an object of tuple<Y, Z>
internally, either by inheritance or as a member element, so there
should not be any copying necessary in the implementation of tail().
TR1 and n2134.pdf do not require a lisp like structure for
std::tr1::tuple<T1,...TN>. As such I do not see a defect.
The example is not written to be a library component. It is possible to
write the unit classes to have a functor template parameter and call
that functor with the result of tr1::get<N>(), in a similiar approach
further its not that complicated an algorithm.
for about 100 lines of code you can provide a tuple_view of the tuple
using boost::mpl then mpl::for_each() can handle any functor that
handles all the distinct types of your tuple.
boost::fusion is a possible replacement, but it is not widely known or
used at this time.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]