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

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-12-17 12:40:38

On 16/12/2019 18:48, Peter Dimov via Boost wrote:
>> One of the big reasons I don't get Peter's caution is that anywhere
>> I've ever worked, nobody has upgraded Boost more frequently than every
>> two or three years, and it's usually a lot more. Maybe I've worked in
>> the wrong places.
> 
> This might well be true in a corporate setting, but downstream packagers
> such as Linux distros, brew, vcpkg etc "upgrade" Boost more frequently
> (on each release) and every breaking change in Boost typically affects
> (many) other packages that then need to be fixed.

That's a good argument.

I guess another reason I feel suspicious of "deprecation warning now,
change default sometime later" is that in my experience people always
forget to do the second step. Then you get libraries - there are a few
popular old C++ ones I won't mention - which implement the deprecated
interface forever. That makes compiling with them just a massive noise
of deprecation warnings nobody acts upon.

It's like all those codebases we've all used which spew warnings, and
nobody ever fixes them.

I think there's a compromise solution here:

Make a new macro:

BOOST_MACRO_DEFAULT_CHANGED(PHOENIX_LIMIT, BOOST_PHOENIX_LIMIT, 107200,
107600)

This expands into something like:

#if BOOST_VERSION >= version && defined(oldmacro)
#error oldmacro was replaced with newmacro in Boost vXXX. Please use
newmacro to avoid this error.
#else
#warning oldmacro was replaced with newmacro in Boost vXXX, and use of
oldmacro will fail the build from Boost vYYY onwards. Defining newmacro
to oldmacro until then.
#define newmacro oldmacro
#endif

I'm not entirely sure how to wrap that into a macro which is portable,
but you get the idea.

Niall