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

From: Emily Winch (emily_at_[hidden])
Date: 2002-08-01 13:07:38

Douglas Gregor wrote:

[ Mike Burton's paper demonstrating a heterogenous value container ]

> Anyone want to figure out a typelist equivalent for this static data structure 
> with dynamic elements? I can't find a good one, and I think that justifies 
> the need for a type vector in MPL. I also think that typelists are 
> well-justified, so conclude what you may.

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. Interestingly, Mike's usage of his container, as described in 
the paper, was confined entirely to for_each style usage, for which a 
cons-list-based container would presumably have no speed disadvantage. 
My paper does present some applications for random access, but I have 
never _used_ it to do those things (except in test code). Boost.Tuple 
has random access, but would customarily be used for such small tuples 
that the list/vector speed difference might not be worth bothering 
about. So at the moment I'm not sure there's a compelling argument for a 
vector-based heterogenous container implementation. (Although I think 
there ought to be).

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. You can't really use 
a type container to create a value container with the same complexity 
characteristics. If people need two kinds of value container, I don't 
think two kinds of type container will help other than for inspiration 
and cut-and-paste purposes.

(I hope I'm wrong, I could easily be).

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());

hmmm...

if(has_parameters<functor>::type)
   do_value_container_for_each
else
   do_type_container_for_each

ugh.

Emily