Boost logo

Boost :

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-12-16 16:38:17

On 12/16/2019 10:22 AM, Niall Douglas via Boost wrote:
> Acting on guidance given to my recent supply to this list of unprefixed
> macros, namespaces etc injected into the global namespace by Boost, I
> have logged a list of all issues with each library, and linked to all
> those from a single issue logged at
> A problem has arisen which requires input from boost-dev. Some Boost
> libraries define as part of their public API a non-BOOST_-prefixed macro
> which changes the definition of their header files e.g.
> (just to be clear, Phoenix is not the only library doing this)
> If we change such macros to be like BOOST_PHOENIX_LIMIT instead, all
> existing code using Boost which sets PHOENIX_LIMIT would potentially
> *silently* break.
> What we could decide to do instead is:
> #if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT)
> #error In Boost 1.xx PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT.
> Please upgrade your code to reflect the new name.
> #endif
> Or one could just leave PHOENIX_LIMIT named as is.
> What would Boost developers prefer we do?

I am with Niall in this as I think that all Boost library macros should
general, deprecate the current macros that do not follow this pattern
and then change them to this pattern in some future Boost release.
Needless to say it is really important that C++ macro names are as
distinct as possible. We all know how ridiculous it is for compiler
implementations to name macros with names such as 'max' and 'min' and
all the troubles such names have caused for scores of C++ programmers
down through the years.

Boost list run by bdawes at, gregod at, cpdaniel at, john at