Subject: Re: [boost] A possible date for dropping c++03 support
From: Roger Leigh (rleigh_at_[hidden])
Date: 2018-08-28 15:22:21
On 28/08/18 11:29, Mike Dev via Boost wrote:
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Gavin Lambert via Boost
>> Sent: Tuesday, August 28, 2018 1:34 PM
>> There is a significant difference between "we've never tried it on XX
>> and so we don't support it", and "it used to support XX and now doesn't".
>> You are trying to cite cases of the former but it is actually the
>> latter. Without further explicit clarification, that invariably means
>> "we have decided to start doing things that do not work in XX", ie. that
>> people can definitely no longer use XX.
> Personally, I don't think this makes it any more difficult for the user to
> understand what is going on. The announcement could be something like
> "Starting from version XX we no longer support c++03"
> And the documentation of any library in XX that is willing to make
> the switch could state something like
> "We no longer support compilation in c++03 mode".
> Irrespective of whether a particular library can still be compiled in c++03
> mode in a particular version, I don't see how this can be interpreted any
> differently than
> "I shouldn't rely on XX working in my c++03 project anymore"
> which is exactly, what it is supposed to mean. Nothing more, nothing less.
[A few comments from an end user.]
In the projects I've maintained, where we already made the transition to
C++11 and later to C++14, this is exactly what we meant.
Some sub-components might have still functioned with C++03, but we
ceased to test this worked, and we didn't make any guarantees that we
wouldn't start using C++11 or 14 features in point releases.
NB. We specified "C++11" and "C++14" as the subset of C++11 and C++14
features supported by specific versions of GCC, Clang and MSVC, so it
was clear what the expectations were, and exactly what we would support,
to avoid using language or library features which weren't available
across the board (modulo special-casing with e.g. #ifdefs if
appropriate). Example: std::regex was buggy with several GCC releases,
so boost::regex continued to be used as a fallback. We never had any
While we had multiple sub-components (much less than Boost though), we
always specified the minimum version across the entire project rather
than allowing individual components to specify different requirements.
This is partly practical--the CI systems we provision have a cost to set
up and maintain, but also it sets expectations for end users,
maintainers and contributors and makes it clear what's supported and
permitted, and what is not. For a project the size of Boost, it would
be useful to set this minimum requirement top down across the board.
A comment about C++03 compatibility. It has a cost, and this is one
example of it:
This is a discussion about Boost.MultiArray. I've been running into
several problems with MPL over the last few years, and it became so
problematic that I ripped out Boost.Variant and replaced it with
mpark::variant as a prelude to C++17 std::variant. The MPL dependency
was the sole reason for this.
MPL is a huge pain when you need to redefine the container size limits.
It can interfere with other MPL-using types, and if used in a public
header can interfere with any other library also using MPL. It becomes
a fragile mess which you can make work with horrible hacks to the
include order for some cases. But a new Boost release can break it all
over again if the include order changes. C++11 variadic templates make
MPL completely redundant.
Is Boost aiming to be up to date and useful for present needs, or is it
going to be tied to the past and be second-rate? What I mean is,
libraries like Variant and MultiArray are inferior to more modern
reimplementations which aren't tied to Boost. It's a shame that the
Boost implementations have stagnated and aren't best in their class.
Dropping C++03 would permit them to drop the MPL dependency.
This is not to disparage the maintenance of these Boost components. The
rationale behind the current approach is sound, and the effort to
maintain backward compatibility is commendable. However, C++11/14
compilers have become standard, and these compatibility compromises are
now increasingly a hindrance; the benefit of them becomes moot as they
become increasingly irrelevant.
Many components could also be updated to use standard language and
library features, dropping a huge amount of legacy cruft which has real
negative consequences for end users.
Regarding some of the comments about platform compatibility, I support
C++11 and 14 on several Ubuntu LTS, CentOS, Clang with Xcode and
FreeBSD, and MSVC releases. For CentOS 7 (and 6), as others mentioned,
we have Devtoolset-7 and EPEL, which provide updated versions compatible
with the base platform. Unfortunately, the base platform also includes
Boost 1.53 which EPEL won't ever update. So we are stuck with 1.53 for
the lifetime of CentOS 7 if we wish to be compatible with the base
platform. So in practice if Boost > 1.68 drops support for C++03, it
has zero practical effect due to the existing requirement to use 1.53.
The same applies to all the other platforms which also provide Boost; we
use the provided version for compatibility unless there's no
alternative. BSD ports and MacOS homebrew are usually pretty current.
On Windows/MSVC we build the latest Boost, but that's not strictly
required, we could stay behind a release or two and patch if needed.
If I had to support a platform with an older compiler after Boost
dropped C++03 (or later) compatibility, I would simply build the last
Boost release supporting that compiler. While the latest Boost release
is nice to have, IME it's rarely been the case that it's essential due
to the need to support several years of Boost versions provided by
various Linux distributions and other package managers. If the next
Boost release required C++11 (or even 17), it wouldn't be the end of the
world, I would simply continue to use 1.67/1.68.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk