Boost logo

Boost :

From: Gavin Lambert (boost_at_[hidden])
Date: 2022-05-06 01:33:10


On 6/05/2022 12:08, James E. King III wrote:
> I for one would enjoy updating Boost.CI and the 16 Boost libraries
> that I maintain to stop running C++03 tests through CI and stop
> claiming support for utterly ancient EOL compilers, as well as
> language levels.

As far as I was aware, it was already agreed several years back that
maintainers of individual "leaf" libraries could decide to stop
supporting pre-C++11 pretty much whenever they like (one or two versions
of deprecation warning appreciated), and that new libraries did not need
to be backwards compatible.

It's a little murkier for libraries that are depended on by other
libraries; there you had to get consensus from the downstream library
maintainers to stop supporting pre-C++11 too, either simultaneously or
earlier.

I would personally argue that it makes sense now to move that forward to
C++14 rather than C++11, but I don't think that's actually been formally
discussed yet.

There's a certain amount of resistance to "forcing changes" on libraries
that don't really get touched year-to-year, because changes require work
and have potential to introduce bugs. While there are some benefits to
rewriting older code to remove workarounds and use more modern patterns
(making future maintainability easier), there is still merit in that
reluctance.

But agreeing to stop supporting C++03 does not necessarily require code
changes -- the absolute minimum would be to just stop running the CI for
it, and an only slightly higher bar would be to change the build
settings to refuse to compile. (Although some people are reluctant to
go even that far -- if they're not actually changing the library to take
advantage of C++11 then there's no technical reason why it wouldn't
compile under C++03, so why block it? But there can be non-technical
reasons why this may still be a good idea.)

There's also some complexity in what "stopping supporting C++03" means,
even if the maintainer does want to make code changes. Like it or not,
there are differences between std:: and boost:: classes even where those
largely intersect (e.g. threading, smart pointers, optional) and some
have features or support that the other lacks. But even where
functionality is sufficiently identical, swapping is an API-breaking
change that will require edits to all downstream code -- probably
trivial ones, and which the compiler will readily identify for you, but
still there nonetheless. And there's a certain reluctance (rightly or
wrongly) to impose that as well. There was an attempt a while ago to
make this the end-user's responsibility to choose between the
implementations via macros and policy templates, but it didn't really
catch on (and I'm not convinced that it should).

Given that C++ itself is largely backwards compatible (and despite the
trash-talk I and others often give it for using the wrong defaults for
everything as a result, this is a good thing); it's usually not hard to
migrate an application code-base from C++03 to at least compiling
without issue in C++14 or beyond, even if not taking advantage of new
features or idioms. So it should not be a difficult barrier to say
"hey, update to C++ab or this library will stop working". Applications
and compilers already have to cope with a mixture of different standard
levels intersecting.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk