On 2/4/23 4:08 AM, Peter Dimov via Boost wrote:
Greetings,
I have a novel idea, let's drop C++03 support.
What I don't understand is how we're supporting C++03 now.
From
https://pdimov.github.io/articles/phasing_out_cxx03.html#_ongoing_costs_of_m...
Summary
We need a policy on phasing out C++03 support in Boost.
C++03 support is holding us back. It impedes development, increases
maintenance costs, increases dependencies, and increases compilation times.
"Library authors and maintainers need to have an approved mechanism for
dropping C++03 support in their libraries."
Authors and maintainers have never been required to support any version
of C++ other than the most recently released one.
"I thought library authors were free to only support C++17?"
This is Boost policy for new library submissions. It’s obviously
unworkable for old and established libraries (that are currently in
maintenance mode) on which many other libraries depend, both in Boost
and outside of it."
For the most part C++ versions maintain backward compatibility with
older versions. So if a library is accepted while the latest C++
version is C++17 and then C++20 comes out, then the library still works
fine. So there is nothing to do.
For example, Boost is a dependency of hundreds, if not thousands, Debian
packages. We have a responsibility to not break them unnecessarily.
"Why not use C++11 only if available?"
In addition to increasing maintenance costs, this also creates other
problems. Let’s consider the scenario in which a Boost library uses, for
example, std::function under C++11 and boost::function under C++03.
namespace lib1
{
#if CXX11
using std::function;
#else
using boost::function;
#endif
struct lib1_type
{
function f_;
};
} // lib1
It’s common, at least under Linux, for user code to use a
system-provided Boost (which is often compiled under C++03), and to use
f.ex. C++14 or even C++17 itself.
This means that lib1_type will have different definitions in the
precompiled Boost library and in user code, which leads to hard to track
undefined behavior.
To avoid these problems, lib1 should always use std::function.
Actually to avoid these problems, we should encourage uses to compile
the boost library from the latest source with the compiler they are
going to use to build their application. (aside, they should be
encouraged to run the test suites of the libraries they are going to use
as well.
FYI - I'm still conflicted as to whether for some given functionality, I
should prefer standard library components or the corresponding boost
components.
Ongoing Costs of Maintaining C++03 Support
Impeded Development
"If a library supports C++03, contributions that use C++11 features have
to either be rejected, or have C++03 workarounds applied to them."
Currently a the maintainer is permitted to select which of these methods
is most suitable in a given circumstance. Nothing more is needed.
"Since C++11 features such as variadic templates and perfect forwarding
significantly increase productivity, this slows down the pace of
development."
Productivity for whom? The library maintainer can now decide whether to
upgrade to newer components or just do nothing. Its up to him and fine
either way.
"Increased Maintenance Costs
Even libraries in maintenance mode need to be updated to support newer
standards, and C++03 code is significantly costlier to change due to,
f.ex. use of the preprocessor to emulate variadic templates and use of
numerous overloads to emulate perfect forwarding."
"Again, currently maintainers can decide among these tradeoffs."
In addition, C++03 compilers are generally older and have more quirks
and issues that need to be worked around.
Again, currently maintainers can decide among these tradeoffs.
"Increased Dependencies
Libraries that support C++03 have to use Boost components even when a
corresponding standard library component exists in C++11. Examples are
std::function, std::bind, std::tuple, std::shared_ptr, ,
std::fpclassify, and so on."
I'm conflicted as too whether std components are better than boost
components. I don't see the benefit of enforcing either preference on
library maintainers.
Increased Compilation Times
One common complaint against Boost is high compilation times. Nearly all
such objections can be traced to use of either the preprocessor library
or Boost.MPL, and the reason is that without variadic templates, a high
number of overloads or specializations need to be generated and parsed.
Again, currently maintainers can decide among these tradeoffs.
Compilation time is not a huge problem for boost components except for
users who don't understand how to properly factor code into source
files. Trying to help these people is beyond the reach of our efforts.
"If we require C++11 ..."
We're currently required a recent standard for new libraries. As far as
I know, all boost libraries currently meet that standard - even those
written 20 years ago and haven't had much maintenance.
"Suggested Policy
A library author or maintainer will be allowed to announce that C++03
support in the library is deprecated."
A library author or maintainer has never been required to support any
specific version of C++ other than the most recent one. Such a policy
is already in place and has never been required.
"This announcement will take the following forms:..."
a) Restate that all boost C++ libraries are required to build and run
with the latest available version of C++.
b) Terminate testing of Boost libraries with versions of C++ earlier
than C++14? or whatever.
"A note in the documentation;"
Include restatement/reemphasis of traditional boost policy as stated above.
"A message issued at compilation time if a library header is included in
C++03 mode."
I don't know what this means. If a header is included in source file
being compiled by a compiler set up to compile C++03 ? or if the source
code only compiles with C++03?(not much code falls in here), or what?
"The recommended form of the code issuing the message will be ..."
if there is no change in the code that happens to supports C++03 why
would any message be necessary?
If the code has been changed so that it requires support for a more
recent compiler version than before, then the following message is
recommended.
#include
#include
#if defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES))
BOOST_PRAGMA_MESSAGE("Compiler support for variadic templates required")
#endif
At least two Boost releases must ship with a deprecation notice whenever
such library changes are made.
=====================================
Reiterating the above action plan:
a) Restate that all boost C++ libraries are required to build and run
with the latest available version of C++.
b) Terminate testing of Boost libraries with versions of C++ earlier
than C++14? or whatever.
Just invoke the above two actions right now. No authority is required
as they don't represent any change in traditional Boost Policy. This
will save us a ton of time.
Robert Ramey
