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. Modularity * That it is modular * That libraries manage their own version (Major.minor.patch) * That libraries manage the dependencies to other libraries without cycles. * 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. Delivery * That the whole Boost manages their own version also (Major.minor.patch) * That we are able to deliver independently Major, minor and patch versions. * 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 dependencies. * This means that we will need to test 3 new release branches. * Build * 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 installed independently) * Install * That we are able to install the libraries independently or as a whole. * Quality * 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 require. ... 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 the committee. * 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 versions? Best, Vicente