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-16 18:33:05

On 16/12/2019 17:27, Paul A Bristow via Boost wrote:

> Is it only Boost libraries that define this macro?

For PHOENIX_LIMIT specifically, both Boost libraries and end user code
might define it. Even to different values, and woe betide you if you
include an unincluded phoenix header afterwards.

> People have bureaucratic hurdles and hoop to jump over through as well as doing
> a quick grep-replace.

I can't say for anywhere I've never worked, but anywhere I've worked
"upgrading our Boost version" is something nobody wants to do, and five
or more years typically elapses before it becomes unavoidable. Then
whichever poor soul gets assigned is the one who must waste a week of
their lives upgrading Boost and validating what has or has not broken.

Given the five year upgrade frequency, everybody accepts that the main
project will get changed, and that stuff will break.

In our case, all our ASIO based code will need to be refactored. That's
another week of work in itself. I also suspect we'll need to refactor
our Regex based code too.

Point is, upgrading Boost is a painful experience which introduces a ton
of code churn, and everybody from upper management downwards understands
this.

> It has been Boost normal practice to give people time to make changes rather
> than breaking things without warning.
> 
> Would it be sensible that we combine these two by doing Peter's suggestion now,
> and Niall's after at least one Boost release?

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.

I will say that 99.9% of the time a Boost upgrade is done because a
customer asked for something where the ancient Boost wouldn't cut it. In
our case, a customer wants C++ 17 support, and Boost 1.64 is very
definitely not C++ 17 clean. So that's two person-weeks at least to
upgrade Boost, and possibly a person-month in total after all the churn
gets shaken out. Assuming a typical cost to a business for a senior
developer, that's 20k of real money per Boost upgrade.

Niall