Re: [boost] [mpl] BOOST_MPL_METAFUNCTION_MAX_ARITY

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-02-22 18:19:43

Jonathan Turkanis wrote:
> I was having a bit of trouble this afternoon getting some MPL code to
> compile, when I realized I was trying to use a placeholder symbol
> embedded in an expression using a metafunction of arity 7. I know that
> the maximum metafunction arity is set at 5, so I tried setting
> BOOST_MPL_METAFUNCTION_MAX_ARITY to 7. This didn't work either,
> because of the preprocessed headers. So I tried defining
> BOOST_MPL_NO_PREPROCESSED_HEADERS. This reduced the number of error
> messages from infinity to 27.
> 
> So I have these questions:
> 
> 1. Am I right that as presently configured mpl::lambda cannot look for
> placeholders inside (fully-curried) metafunctions of arity > 5?

Yes. You either need to regenerate preprocessed headers for the new 
configuration, or to go with BOOST_MPL_NO_PREPROCESSED_HEADERS.

> 2. Are preprocessed headers used just to cut compilation times, or for
> some more fundamental reason? 

The former, and also to workaround a bug present in old EDG front-ends.

> If it is just to save time, how much
> time does it save?

IIRC, it makes a noticeable difference for EDG-based compilers (10-20%, 
I think), and not so noticeable for others (< 5%). It's been a long time
since I did the measurements, so chances are things changed since then. 
It's always safe to do the comparison yourself, just to be sure :).

> 3. Is there any way to circumvent the preprocessed headers entirely to
> compile mpl with a different max arity?

Defining BOOST_MPL_METAFUNCTION_MAX_ARITY together with 
BOOST_MPL_NO_PREPROCESSED_HEADERS the should do it. If not, it's a bug.
I'll check if that's the case with the current CVS state.

--
Aleksey Gurtovoy
MetaCommunications Engineering