On 5/3/2011 10:36 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, May 2, 2011 at 2:31 PM, Mathias Gaunard< mathias.gaunard@ens-lyon.org> wrote:
On 02/05/2011 13:18, Thomas Heller wrote:
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.
What is in in Phoenix that intrinsically requires this?
Is it just for the unit tests? Then manually set the right values just for the unit tests.
I'm guessing it was probably a documented default setting in v2, hence I'm guessing this is an effort to maximize backward compatibility.
I can think of 2 reasonable and safe things: - #error if the preprocessor constants from other libraries aren't satisfactory (as already suggested); or - define the default Boost.Phoenix preprocessor constants in terms of the other Boost library preprocessor constants, and warn about the backward incompatibility in the documentation.
I'm with the first: #error if the preprocessor constants from other libraries aren't satisfactory (as already suggested); Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com