Re: [boost] Re: MPL containers and algorithms

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-11 20:38:05

On Sunday 11 August 2002 01:41 am, Paul Mensonides wrote:
> > Just to poke my head in again -- AFAIK, Burton et al. were using
> > heterogeneous value lists of 10,000 elements (multi-day compile times,
> > but really fast code...).
>
> The question is, would this be easier to do with an external generative
> program?

No. They used some syntactic tricks so that the polymorphism they needed could 
either be expressed dynamically (virtual functions) with the data in a 
run-time container (std::vector) or statically (function objects) in a 
compile-time container (a typevector). The generator would have to be 
extremely powerful. And besides, isn't metaprogramming a way to _avoid_ extra 
tool dependencies?

> > Again, I'd like to refer to the heterogeneous value lists used by Burton
> > et al. Their use of larger heterogeneous value lists syntactically favors
> > type vectors. I explained their approach in the thread "Potential use for
> > multiple sequence types".
>
> What do you mean by 'syntactically'?  Do you mean something like (a, b, c)
> is easier on the eyes than (a, (b, (c, nil)))?  In that case, I agree. 
> However, cons-style lists could be easily made to look like (a, b, c) for
> the convenience of users.  10,000 elements would, of course, still take an
> obnoxiously long time.

Here are some entries from the typevector they used:

template<> struct ParticleArray<0> { 
  Neutron particle; ParticleArray() : particle(...) {}
};

template<> struct ParticleArray<1> { 
  Proton particle; ParticleArray() : particle(...) {}
};

It's trivial to write out heterogenous value containers this way. I can add 
another element, along with the initialization of its run-time value, in just 
a few lines of code. There are no predefined library limits, I don't have to 
ask MPL to generate mpl::list10000 along with a constructor that looks like:
  
  list10000(const T1& t1, const T2& t2, ..., const T10000& T10000)

It's simple, intuitive, and efficient. All information for each element is in 
a single place (a typelist would require separation of the type from the 
value, and create a ton of work for the compiler's inliner). Why would we 
want to use a typelist for this?

> By the way, I fully believe that type-vectors are more efficient that
> cons-style lists.  I just don't think that we need both.

Burton et al. were working with finite element analysis, and that means two 
dimensional random access. Would you still use a typelist for that?

        Doug