Re: What to do about Boost libraries which use user-defined macros which are not BOOST_ prefixed

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
> https://github.com/boostorg/boost/issues/352.
> 
> 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.
> 
> PHOENIX_LIMIT
> 
> (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 
begin with BOOST_SOMELIBRARY_UPPERCASENAMEOFMACRO_ETC. Maybe we can, in 
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.