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