From: Emily Winch (emily_at_[hidden])
Date: 2002-08-01 14:23:20
Douglas Gregor wrote:
> On Thursday 01 August 2002 02:07 pm, Emily Winch wrote:
[ you can make cons-list-style heterogenous value containers ]
> Sure it _can_ be done, but would you do it for 10,000 elements? Take a look at
> the tuple constructor for this in tuple/detail/tuple_basic.hpp:
>
> tuple(typename access_traits<T0>::parameter_type t0,
> typename access_traits<T1>::parameter_type t1,
> typename access_traits<T2>::parameter_type t2,
> typename access_traits<T3>::parameter_type t3,
> typename access_traits<T4>::parameter_type t4,
> typename access_traits<T5>::parameter_type t5,
> typename access_traits<T6>::parameter_type t6)
> : inherited(t0, t1, t2, t3, t4, t5, t6, detail::cnull(),
> detail::cnull(), detail::cnull()) {}
>
> There are 9 more of those, so a full set for a tuple of 10,000 elements is
> 10,000^2. Granted, you can just have one constructor with 10,000 arguments if
> you are very careful with references, but I'd still be a little worried about
> all of the "Implementation quantities" we're blowing past (think of mangled
> name for that constructor...).
Hmmm. I think the application for these containers in Mike's paper might
well require enough elements to make the memory used by the vast
recursion depth of a cons-style list a serious consideration. But there
still isn't much point debating it without concrete data about real life
compiler problems, timing, and memory usage.
> Contrast this with the approach taken by Burton et al. using compile-time
> vectors as heterogeneous value containers it's much easier to create a
> 10,000-element heterogeneous value container, and nobody needs to extend
> Boost.Tuples to 10,000 template parameters.
If Boost.Tuple was PP'ified, nobody would need to do that.
>>In any case, it's not the case that a requirement for a certain
>>implementation of a heterogenous value container implies a requirement
>>for a type container with the same implementation.
>
> Isn't that tantamount to saying that there is no reason to manipulate the
> types of a heterogeneous container as a metaprogram? That says that we'd
> never want to search for a particular type in a compile-time vector?
I'm not quite sure how your conclusion follows from my premise. You
don't need a typelist implementation _at all_ to search for a type in a
compile-time vector.
>>I'm really very interested in how a set of semi-compile-time containers
>>and algorithms like Boost.Tuple and my associative_list would fit in
>>with the MPL. I can imagine a for_each that says (pseudo meta-code)
>>
>>if(container::tag == type_container)
>> do_type_container_for_each
>>else
>> do_value_container_for_each
>>
>>But what if you want to be able to write
>>
>>tuple<int, double, char> foo(1, 2.3, 'c');
>>
>>for_each(begin<foo>(), end<foo>(), do_something_with_foo_values());
>>for_each(begin<foo>(), end<foo>(), do_something_with_foo_types());
>
>
> My knee-jerk reaction is that the first for_each loop here is more likely to
> be necessary. If you're using a heterogeneous container, more than likely
> than not you're interested in operating on the values in that container when
> you're calling the run-time for_each. Otherwise you'd be calling a
> compile-time for_each.
That was the intention - to call a compile-time for_each. It's certainly
more likely that you want to manipulate the values in your value list
(or you would have used a typelist instead) but nothing prevents you
from wanting, say, to print out the types occasionally. For example:
typedef tuple<foo, bar, wiz*, donkey*> my_tuple(1, 2, &the_wiz,
&the_donkey);
// already using an algorithm over the types, not the values
typedef remove_if<my_tuple, is_pointer<_1> >::type my_pointerless_tuple;
// I have answered my own question, in actually trying to write this
// out!
// check that the remove_if did what we intended
for_each<my_tuple>(print(std::cout)); // print the types
// get on with the rest of the program
for_each(my_tuple, print(std::cout)); // value algorithm
Of course the compiler will do that all for us with no problem.
Emily