Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-04 16:48:19

Brian McNamara <lorgon_at_[hidden]> writes:

> I should point out that, in fact, I did not implement each
> trait-of-interest separately; for a ternary function F, you can say
> monomorphic_traits<F>::first_argument_type
> monomorphic_traits<F>::second_argument_type
> monomorphic_traits<F>::third_argument_type
> monomorphic_traits<F>::result_argument_type
> for example. However, in practice, you do want all of these traits
> together (typically if you need one, you need them all). The point is,
> I separated this set of tightly-related traits from the other traits
> already associated with the fullN classes. And this was a big
> efficiency win.

This should be, IMO:

    argument_type<F, mpl::int_<1> >::type
    argument_type<F, mpl::int_<2> >::type
    argument_type<F, mpl::int_<3> >::type
    argument_type<F, mpl::int_<0> >::type // I'm flexible on this

OR, what I do in Boost.Python, essentially:

    signature<F>::type -> mpl::vector<result,arg1,arg2,arg3>

Either way leaves you with fully-interoperable metafunctions.

> It is not clear to me what the general design principle ought to be.
> On the one hand, it makes "conceptual sense" to group together related
> traits into one traits class. On the other hand, doing so often means
> you get traits-blob compile-time inefficiencies, which in the worst
> case can be horrible (as I described above).

It helps to think of metafunctions instead of traits.

> Actually, duh, a middle-of-the-road trade-off just occurred to me.
> Right now, when I say monomorphic_traits<F>, it computes all the
> associated typedefs. In order to do the computations individually, all
> I have to do is change it to, e.g.
> monomorphic_traits<F>::first_argument_type<>::type
> monomorphic_traits<F>::second_argument_type<>::type
> ...


> The nested templates are named as the individual traits of interest, and
> they each have a default (dummy) parameter. As a result, each
> individual trait is only computed on demand (and is also individually
> MPL-able). But all the related traits are grouped into a common
> "supertraits" class, which groups related traits conceptually and also
> helps prevent namespace pollution. I think this may be a
> nearly-perfect overall solution which gives the best of both worlds.
> That looks really clever to me, and I'd appreciate comments on the idea
> (especially from David).

Sorry, looks uglier than my first alternative, and much more verbose,
and much *less* MPL-able. How do you express


with that system??

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at