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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-01 13:51:01

On Thursday 01 August 2002 02:07 pm, Emily Winch wrote:
> Are you asking if it's possible to make a cons-list-like heterogenous
> value container? In which case, yes it is. See Boost.Tuple, or
> http://groups.yahoo.com/group/boost/files/associative_list/ (and also
> http://oonumerics.org/tmpw01/winch.pdf) for one with algorithms and
> iterators. 
[snip]

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...).

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.

[As a side note, we used the same compile-time vector style as Burton et al. 
did, though for a purely metaprogramming project (no run-time counterpart). 
Our reasoning there was that we needed to build a compile-time vector from a 
set of types spread across library headers and user source code. Incrementing 
was done via preprocessor macros so that we could fill in each of the vector 
elements in order.]

> 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 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.

        Doug