From: Edward Diener (eldiener_at_[hidden])
Date: 2019-12-17 13:52:49
On 12/17/2019 7:40 AM, Niall Douglas via Boost wrote:
> 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,
> 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.
> #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
A macro can not expand to further preprocessor statements.
> I'm not entirely sure how to wrap that into a macro which is portable,
> but you get the idea.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk