On Mon, May 2, 2011 at 10:36 PM, Thomas Heller <thom.heller@googlemail.com>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