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