Re: [boost] typelists: MPL tutorial + partial review

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-14 14:10:29

----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>

> I understood that intention, I just thought that it's probably not worth
to
> get into such details in the second example in the tutorial :). As I see
it,
> presenting a simple implementation first, and then gradually showing how
to
> improve/optimize it (one step at the time, and if there is a need to
improve
> :), is probably the best strategy here.

I'm not sure your approach will be more understandable. Decomposing things
into simple elements makes things more comprehensible, IMO. If you show
people Mat's hierarchy diagram, and say "each * is one of these Inherit2
classes", I think they'll be able to follow it much more easily. Otherwise,
how many levels of class nesting have you got? Three! And two of the levels
are templates! It is also more idiomatic to use a typedef expression as the
result of apply.

> > Don't you think it's time to reveal the beginnings of the
> > docs that already exist?
>
> Hmm, I am not sure. The docs are still very immature, don't you think so?

Perhaps. I don't think it would hurt too much. You might even get some
contributions, like for example what Mat wrote.

> > > > * MPL seems to tax the compiler somewhat more than Loki.
> > >
> > > This is true right now, but to my best knowledge there are
> > > no inherit limitations in the library design that would prevent one
> > > to have as effective (in terms of compile-time resources) type list
> > > and algorithms implementation as you might possibly have.
> >
> > There is a small matter of the use of traits for detecting sequence
> > termination, but I am not yet convinced that this actually causes any
> > significant overhead.
>
> Theoretically (if you have a lot of time, and/or if it's really needed),
you
> can specialize (read "re-implement") every library algorithm for your
> specific type of compile-time sequence, so there will be no overhead from
> MPL side whatsoever. In practice (at least that's the goal :),
implementing
> a few core sequence operations such as 'begin/end', 'insert', etc. is
> usually enough to get all other MPL algorithms "for free", or only for a
> small price in compile-time performance. In fact, as we know, aggressive
> internal application of such techniques as loop unrolling in many cases
> could lead to the situation when a meta-program written using MPL is
_more_
> effective than a hand-coded straight-forward recursive implementation of
the
> same algorithm.

I'm not sure we gained any compile speed from that - I was just trying to
work around a nesting depth limitation. However, from what I've learned of
the reasons some of these compilers are slow, limiting nesting could buy a
/lot/ of speed. That would certainly be a good argument for library-supplied
iteration.

-Dave