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-03 11:30:20

On Mon, May 2, 2011 at 10:36 PM, Thomas Heller
<thom.heller_at_[hidden]>wrote:

> 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:
>
[...]

> > > 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?
>

Boost.Phoenix.

> I needed to redefine these constants to make Phoenix work as it is.
>

I don't think it is a viable solution for Phoenix to define/redefine the
preprocessor constants of other Boost libraries (as Steven pointed out).
Mathias suggested having a dedicated header for this, presumably to be
#include'd before any other headers in a cpp, but I don't know if this is a
precedent that should be set.  I can imagine quite a dependency mess if
other libraries start following this same practice.

> The "#error"s if the constants do not satisfy the needs are already there.
> Apparently that doesn't solve the problem.
>

How doesn't it solve the problem?  I would assume you are #include'ing the
appropriate MPL, Fusion, etc. headers prior to checking these constants.

Working with the default LIMITs already predefined by default only shifts
> the
> problem.

...to the user.  An inconvenience, but better than the current solution, I
think...

> If a library needs to increase the limit the topic "[boost][library]
> not playing nice with other libs" will pop up ...
>

Correction:  If a library attempts to increase the limit ... (as
Boost.Phoenix currently attempts to do)

Ideally, the #error message would indicate what the user needs to do to get
everything working in harmony.

I think, in this case, so that Boost.Phoenix works out of the box, we might
have to a accept a breaking change in the default preprocessor constants...

- Jeff