Re: [boost] A possible date for dropping c++03 support

On 28/08/18 11:29, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost 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 complaints. 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: https://www.reddit.com/r/cpp/comments/99cggw/boostmultiindex_introducing_c17... 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. Kind regards, Roger