Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-07-31 16:18:19

> Fair enough, but you should notice that your entire argument seems to based
> in the axiomatic statement that I remarked above.
> IMO, the bottom line of this discussion is that Andrei and you think that
> compile-time programming differs from run-time programming so much that, as
> you said, the conventional run-time needs (such as efficient random access
> time, head-tail appending time, insertion time, permutation time, etc...)
> don't apply to compile-time.

Not between run-time and compile-time.  Between imperative and functional
programming.  Template metaprogramming, regardless of what it looks like, is
functional programming.

> You have to prove, or at least, explain a lot more deeply, this point
> precisely. Why different sequence-types are undoubtly useful in run-time,
> but not in compile-time? It all boils down to this.

Primarily, because the reasons that we have multiple run-times containers don't
apply to functional programming.  For example, the only reason that you wouldn't
always use std::vector as your sequence type is that insertion requires copying
all of the elements and possibly reallocating all of the memory.  You use
std::vector for fast access, and push_back is on average very efficient.  This
is unlike template metaprogramming in nearly every regard.  Insertion *always*
requires copying, and (if you count the innards of the compiler) *always*
requires reallocating.  You use std::list to avoid this cost of insertion.  It
is fast because it only has to *modify* a few pointers, but this _is not
possible_ in a functional environment.  You have to copy the entire sequence
anyway.  Furthermore, this copying is not particularly expensive because it is
mostly just copying a reference into some compiler's internal structure of
identifiers.

Given that this is the case, the most efficient solution would be to always use
a tuple-like (i.e. vector-like) container that can hold a huge number of
elements.  On the other hand, the most extensible solution would be to use a
cons-style list.  One or the other is fine, but both is unnecessary.

Paul Mensonides