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

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-12-18 06:36:07

David Abrahams wrote:
> > 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. 

You are right, I didn't think about the diagram (just never needed it myself
:), and keeping it clean is certainly an important goal. 

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

Agree.

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

I remember that :). I meant "resource-effective" as well as
"speed-effective".

> However, from what I've learned of the reasons some of these 
> compilers are slow, limiting nesting could buy a /lot/ of speed. 

That's certainly true.

> That would certainly be a good argument for library-supplied
> iteration.

It is :)

Aleksey