Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk