Re: [boost] [MPL] Potential use for multiple sequence types

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