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