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
> 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.
> 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 www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk