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

Subject: Re: [boost] [phoenix] not playing nice with other libs
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-05-02 22:36:30

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.

- Jeff