[boost] Re: review request: container_traits

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

Ouch.

> 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

        argument_type<F,_1>::type

with that system??

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com