Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk