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

Subject: Re: [boost] [phoenix] not playing nice with other libs
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-05-02 07:28:21

On Mon, May 2, 2011 at 1:18 PM, Thomas Heller
<thom.heller_at_[hidden]> wrote:
> On Mon, May 2, 2011 at 12:54 PM, Eric Niebler <eric.niebler_at_[hidden]> wrote:
>> 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).
>
> Anybody got any ideas?
>
> One idea that comes to my mind is having a phoenix::proto_expr,
> which is a proto::basic_expr, basically.
> Not sure if that would work though

Another solution could be to not define these constants in the
accompanying C++ headers
but define it in the Jamfiles for the different projects (if it needed
to be changed).
Boost.Build could then magically select the maximum and use it to
build the current TU.
However, this would require a major change, in probably any library,
and the usage of boost
headers wouldn't be as straight forward as it is now ...