From: David Abrahams (dave_at_[hidden])
Date: 2003-10-10 13:47:19
Mat Marcus <mat-boost_at_[hidden]> writes:
>> Also, although Metafunction is more fundamental, it requires more
>> infrastructure (lambda) to do higher-order functional programming
>> with it. A metafunction class can be passed to a metafunction
>> directly. I believe there *may* be good efficiency reason to
>> preserve its current definition.
> Sure, I'm familiar with the use of metafunction classes. Let me just
> make sure that I understand the tradeoff you are describing here. I
> might like to relax the requirements on models of metafunction class
> in order to admit a wider set of representatives. But there is no
> known way to avoid the compile time inefficiencies incurred by the
> external apply over the nested apply. Is that the point?
Yup. If you want the ultimate low-overhead higher-order metafunction
argument, you want a metafunction class. Adding a level of
indirection through an external apply does incur inefficiency.
> In the runtime world we have inlining and as a result I'm used to
> waving my hands and saying that the generic style doesn't incur
> extra overhead on a "reasonable compiler". I suppose there's not
> really an analog in the compile time world.
Nope, not until we have a meta-compilation phase. The fact that you
only pay once for instantiation is close.
> If the only requirement on metafunction classes was the invokability
> of the free apply, MPL could perhaps look first to see if a nested
> version existed, but even the looking takes time.
-- 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