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-03 01:36:39

On Tuesday, May 03, 2011 07:08:54 AM Joel de Guzman wrote:
> 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.

Its not just for the unit tests. Its for being API compatible with Boost.Bind 
and backwards compatible with Phoenix V2.

> > 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);

How should this work? Which library is going to emit the error?
I needed to redefine these constants to make Phoenix work as it is.
The "#error"s if the constants do not satisfy the needs are already there.
Apparently that doesn't solve the problem.

Working with the default LIMITs already predefined by default only shifts the 
problem. If a library needs to increase the limit the topic "[boost][library] 
not playing nice with other libs" will pop up ...