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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-12 13:46:11

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

> > * 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. Have you run the tests we discussed?

> It's not exactly that. Type lists are not padded with unused types, these
> types are just a part of type list generator "signature", and that's why
> they appear in the error messages. One way to get rid of them is to
inherit
> from type_list instead of typedef-ing it:
>
>    struct my_list : boost::mpl::type_list<char,short,long> {};

I used that trick a lot when I was using MPL. Another advantage is that
whenever you can do that, it can make the compiler much happier because it
only has to manipulate "my_list" instead of some complicated type, at least
at the outer level metafunctions. It also can make error messages much
easier to grok.

Note that this trick is one that prevents the "straightforward" use of
specialization for algorithm termination, since the list type isn't
neccessarily an instantiation of type_list_node (or whatever your 'cons'
cell is). OTOH, the traits-based termination detection allows:
    1. Different sequence types
    2. An easy non-recursive syntax for specifying type lists
    3. The above trick

I think it's a good tradeoff.

> Another way is to write
>
>     typedef boost::mpl::type_list<char,short,long>::type my_list;

This one makes the compiler do a bit more work, but no more than with a
"classic" recursive type list formulation, since that's exactly what my_list
is in this case.

-Dave