Re: [boost] [phoenix] not playing nice with other libs

Subject: Re: [boost] [phoenix] not playing nice with other libs
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-05-03 01:08:54

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_at_[hidden]>  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