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

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-12-14 13:19:11

David Abrahams wrote:
> ----- Original Message -----
> From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> 
> > One particular difference here, comparing to the Dave's 
> > version, is that his code guarantees that nodes in the 
> > hierarchy will have a particular type (InheritTwo<>), 
> > while mine doesn't ('cause I don't think that's needed),
> > and in theory it saves a few more lines :).
> 
> The real reason I did it was to cut down on the complexity of 
> the name of the class produced by GenScatterHierarchy. 

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.

> Otherwise, the resulting class would look something like this:
> 
> node_generator<MyTransformation>::apply<
>     node_generator<MyTransformation>::apply<
>         node_generator<MyTransformation>::apply<
>             empty
>             , Base1
>         >::type
>         , Base2
>     >::type
>     , Base3
> >::type
> 
> instead of:
> 
> inherit_two<
>     inherit_two<
>         inherit_two<
>             empty
>             , Base1
>         >
>         , Base2
>     >
>     , Base3
> >
> Carrying all of that extra type information around is hard on 
> the eyes in an error message, and can make compilers 
> (especially EDG-based ones) incredibly S-L-O-W.
> 
> > > * MPL needs documentation now. I believe some mpl naming
> > > conventions could be improved as well.
> >
> > Do you have any specific suggestions in mind (besides 'for_each' :)?
> 
> 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?

> > > * 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.

> Have you run the tests we discussed?

Nope, but measuring and reducing the abstraction penalty is the second item
in the library's to do list (after the docs).

Aleksey