Message du 02/05/11 13:19 De : "Thomas Heller" A : "Eric Niebler" Copie à : "Boost mailing list" Objet : Re: [boost] [phoenix] not playing nice with other libs
On Mon, May 2, 2011 at 12:54 PM, Eric Niebler wrote:
The following trivial program fails to compile:
#include #include
It generates the following:
In file included from ../../../../branches/release/boost/numeric/conversion/detail/is_subranged.hpp:17, from ../../../../branches/release/boost/numeric/conversion/detail/conversion_traits.hpp:21, from ../../../../branches/release/boost/numeric/conversion/conversion_traits.hpp:13, from ../../../../branches/release/boost/numeric/conversion/converter.hpp:13, from main.cpp:2: ../../../../branches/release/boost/mpl/multiplies.hpp:38: error: wrong number of template arguments (12, should be 5) ../../../../branches/release/boost/mpl/aux_/preprocessed/gcc/times.hpp:68: error: provided for ‘temp late struct boost::mpl::times’
Phoenix is changing the following fundamental constants:
BOOST_PROTO_MAX_ARITY BOOST_MPL_LIMIT_METAFUNCTION_ARITY BOOST_PROTO_MAX_LOGICAL_ARITY BOOST_RESULT_OF_NUM_ARGS
IMO, Phoenix shouldn't be touching these. It should work as best it can with the default values. Users who are so inclined can change them.
Eric, This problem is well known. As of now I have no clue how to fix it properly.
Let me sketch why i changed these constants: 1) Phoenix V2 has a composite limit of 10: This is equivalent to the number of child expressions a expression can hold. This is controlled by BOOST_PROTO_MAX_ARITY for the number of template arguments for proto::expr and proto::basic_expr 2) Boost.Bind can take up to 10 parameters in the call to boost::bind
The default BOOST_PROTO_MAX_ARITY is 5.
The BOOST_RESULT_OF_NUM_ARGS constant needed to be changed because i needed to provide 11 arguments in a "call" to boost::result_of. But i guess a workaround can be found in this specific case.
I wonder what qualifies as "User". Phoenix is certainly a user of mpl, result_of and proto. Spirit is a user of proto and phoenix. Spirit needs an arity of 7 (IIRC).
I agree. A library using another library having a max number of parameters must redefine it if the value is not enough big to its needs.
Anybody got any ideas?
Is there a way to avoid using the preprocessed MPL files (BOOST_MPL_PREPROCESSING_MODE?) Best, Vicente