Opened 9 years ago

Last modified 9 years ago

#9295 new Bugs

PHOENIX_LIMIT macro clash: property_tree -- log/sink

Reported by: Johan Lundberg <lundberj@…> 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 Andrey Semashev, 9 years ago

Cc: Andrey.Semashev@… added
Component: logphoenix
Owner: changed from Andrey Semashev to Thomas Heller

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.

comment:2 by John Fletcher <J.P.Fletcher@…>, 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.

in reply to:  2 comment:3 by John Fletcher <J.P.Fletcher@…>, 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 John Fletcher <J.P.Fletcher@…>, 9 years ago

A conditional will not work for the case where the other header comes second.

comment:5 by John Fletcher <J.P.Fletcher@…>, 9 years ago

I have run the phoenix tests offlien without the definition of PHOENIX_LIMIT and nothing breaks.

comment:6 by John Fletcher <J.P.Fletcher@…>, 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.

Note: See TracTickets for help on using tickets.