Subject: [boost] Boost 2.x - (Was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-05-22 14:28:28
Le 21/05/2016 à 18:09, Edward Diener a écrit :
> On 5/21/2016 11:52 AM, Vicente J. Botet Escriba wrote:
>> Wether we want a "C++14 only" Boost version is another thing.
> What could it possibly achieve to have a Boost with only C++11 or
> above libraries or a Boost with only C++14 or above libraries, as
> opposed to having Boost as we have it now in which each library can
> choose what level of C++ support it requires ? I would really like to
> get a technical answer, as opposed to an emotional response about
> "moving forward" and "looking to the future" and "serving the entire
> C++ community", to that question by those who propose such ideas.
I'm not saying that Boost 1.x must be stopped. Not all the members of
the Boost community have the same needs. In particular, I could need a
C++98 Boost version at work, but I would appreciate a C++14 at home. I
have moved recently to a project using C++11 and Boost. I will comeback
to you with my experience.
Starting a new Boost version supporting only new compilers has two
sides: starting a new version and on new compilers.
What I would expect from a new Boost 2.x version?
* That avoids the issues we are facing with the current Boost 1.x version.
* That it is modular
* That libraries manage their own version (Major.minor.patch)
* That libraries manage the dependencies to other libraries without
* That the included libraries ensure ABI compatibility between minor
versions (I don't know how to check this)
* That we manage library and point/patch versions.
* That the whole Boost manages their own version also
* That we are able to deliver independently Major, minor and patch
* A patch version could consists in upgrading all the libraries to
its last patch version respecting the Major and Minor versions and
respecting the dependencies.
* A minor version would upgrade only the libraries with minor
versions and respecting the Major version and the dependencies.
* A Major version would upgrade all the libraries respecting the
* This means that we will need to test 3 new release branches.
* That we can build all with CMAKE (as it is a standard de-facto).
* Other build systems could be used as well (as far as they can be
* That we are able to install the libraries independently or as a whole.
* That we ensure some quality KPIs. We would make use of anything
available to us as static checkers, sanitizers, rules checkers, code
coverage, profiling, ....
* Ownership and evolution
* That we work as a whole, a library shouldn't be owned only by its
initial author. We need to avoid unmaintained libraries.
* That any additional features are reviewed to ensure the quality we
What I would expect from a new Boost 2.x version requiring C++11, C++14
or C++1z compiler support?
* don't reinvent the wheel.
* that it is adapted to the new compiler and library version, e.g. move
semantics, initializer_list, constexpr, noexcept, ....
* that it would help to identify possible issues on the standard, the
compilers and standard library implementations.
* that there is a C++ standard proposal that follows the acceptance of a
library into Boost, either by the author or someone else ... The
feedback from the Boost reviews is not the same than the feedback from
* I would appreciate to have the C++14 library additions that don't
depend on any additional C++14 language feature to be available for
C++11 compilers in the form of an extension library (we couldn't be able
to modify classes existing in C++11, but we could add new ones). The
same applies for C++1z and C++11/C++14 compilers. This should help as a
bridge between language versions.
You may have other expectations.
What the authors of such libraries could gain?
* I guess that supporting less compilers would allow to have a library
code that has less portability issues and that it is easier to maintain.
* C++11/14 offers a lot of things that helps to simplify the code "less
code more software".
And last, what the user of such a library could gain?
* a library that works better with the new standard library
* able to install the libraries independently
* less bugs ( remove all the ones related to portability )
Maybe it is worth having a new Boost 2.x version for C++98 that respects
the Boost 2.x expectations (I have no time to work on this).
I repeat myself : whether we want to do it is another question.
Is it worth doing it? I don't know. It needs a lot of resources and energy.
What we as a Boost community could lost having additionally these new
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk