Opened 9 years ago
Last modified 9 years ago
#9295 new Bugs
PHOENIX_LIMIT macro clash: property_tree -- log/sink
Reported by: | Owned by: | Thomas Heller | |
---|---|---|---|
Milestone: | To Be Determined | Component: | phoenix |
Version: | Boost 1.54.0 | Severity: | Regression |
Keywords: | Cc: | Andrey.Semashev@… |
Description
Components:
- spirit
- phoenix
- log
- property_tree
The following does not compile using gcc 4.8.1 or 4.7.2 (linux) using default warning options:
#include "boost/property_tree/json_parser.hpp" #include "boost/log/sinks.hpp"
The reason is that there are two (different?) definitions picked up, from deep within the include graphs:
boost/phoenix/core/limits.hpp:26 #define PHOENIX_LIMIT BOOST_PHOENIX_LIMIT boost/spirit/home/classic/attribute.hpp:30 #define PHOENIX_LIMIT 6
(Note to others: A workaround for cases where the two are not truly used together is to use a pimpl.)
Change History (6)
comment:1 by , 9 years ago
Cc: | added |
---|---|
Component: | log → phoenix |
Owner: | changed from | to
follow-up: 3 comment:2 by , 9 years ago
I don't see why boost phoenix should define PHOENIX_LIMIT at all for its own use. I will test out offline not defining it and see what if anything breaks and fix it. It could break old code from Phoenix V2 however and so a conditional may be better with a note that is not encouraged.
comment:3 by , 9 years ago
Replying to John Fletcher <J.P.Fletcher@…>:
I don't see why boost phoenix should define PHOENIX_LIMIT at all for its own use. I will test out offline not defining it and see what if anything breaks and fix it. It could break old code from Phoenix V2 however and so a conditional may be better with a note that is not encouraged.
I meant that it is not encouraged.
comment:4 by , 9 years ago
A conditional will not work for the case where the other header comes second.
comment:5 by , 9 years ago
I have run the phoenix tests offlien without the definition of PHOENIX_LIMIT and nothing breaks.
comment:6 by , 9 years ago
boost/sprit has this:
boost/spirit/home/classic/attribute.hpp:29-31 #if !defined(PHOENIX_LIMIT) #define PHOENIX_LIMIT 6 #endif // !defined(PHOENIX_LIMIT)
so I have put this conditional code into boost/phoenix :
boost/phoenix/core/limits.hpp:30-32 #if !defined(PHOENIX_LIMIT) #define PHOENIX_LIMIT BOOST_PHOENIX_LIMIT #endif
I will put that on test in develop.
I think this needs to be resolved by Boost.Phoenix v2/v3 and Boost.Spirit maintainers. I don't see what can be done on Boost.Log part. My (naive) suggestion is to define PHOENIX_LIMIT in boost/phoenix/core/limits.hpp conditionally, or drop it altogether in favor of BOOST_PHOENIX_LIMIT.