[boost] Re: Review Request: FC++

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.

Yup.

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