[boost] Re: MPL containers and algorithms

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-07-28 22:17:25

"David Abrahams" <dave_at_[hidden]> wrote in message
news:010f01c23667$b45fe4f0$6801a8c0_at_boostconsulting.com...
> From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
>
> > An argument that was aired is that various compile-time structures would
> > lead to different compile times. Consequently, the argument goes, the
> > developer would select the structure that leads to the least memory
> occupied
> > and the fastest compile time. However, experience shows that various
> > compilers prefer various data structures, depending on how the compilers
> > implement templates. So if one is to write portable code, there is no
> clear
> > choice of a structure over another.
>
> Hi Andrei,
>
> Just a few comments:
>
> 1. Which experience are you talking about?

I was talking about my own experience. For example, MWCW handles
dot-typelists so fast, I had doubts it compiled the code correctly :o). Even
in cases where dot-lists are not supposed to be as efficient as vectors.

> 2. It's not just about compilation speed, although that's a real factor
> also. There are other compilation resources which count as well, such as
> depth of template instantiation. Some compilers have internal limits on
how
> much nesting they will allow... and this too affects speed on some
> compilers.

That is true, and I believe that by and large, a library for compile-time
processing would be concerned with that (although to some compile time is in
a sense "free"). The way C++'s template engine is structured, however, leads
me to think that dot-lists are just fine. Consequently, MPL's support for
multiple containers, à la STL, is misdirected and looks more like a solution
to no problem.

By the way, it would be convincing if MPL would come with examples that
prove the advantages of its design.

> 3. Data structures offer more than just linear constructions. For example,
> given the right iterators we can treat a tree as a sequence. I realize you
> can represent a tree using dot typelists, but without iterators you need a
> special algorithm to flatten the tree before you can use it in sequence
> algorithms.

An s-expression is a tree alright. You wouldn't have to flatten it in order
to process it. LISP provides many examples of elegant tree processing, and
all it uses as data structures is the dot list.

Andrei