On 11/29/2020 10:47 AM, Mike via Boost wrote:
Gesendet: Samstag, 28. November 2020 um 18:32 Uhr Von: "Edward Diener via Boost"
On 11/28/2020 11:47 AM, Mike via Boost wrote:
Gesendet: Samstag, 28. November 2020 um 13:28 Uhr Von: "Paul A Bristow via Boost"
The difficulty with our strategy is selling it to potential users who are desperate to be able to tick a box marked 'Cxx-supported'. It gives them a warm feeling, but little in reality.
Aren't you dismissing the voiced concerns too easily? I want to be able to interact with libraries using standard library vocabulary types and I don't want my compiletimes to explode when using them. Supporting old c++ standards as many boost libs do can be a problem for both of those goal: - Apparently a lot of the compilation slowdown is due to the use of boost.MPL, which could be replaced in c++11 by mp11 or language constructs.
Proof please about compilation slowdown regarding MPL versus mp11.
Thats what I've heard repeatedly here on the ML and on slack. I see that Peter has supplied a link further up in this thread: http://metaben.ch/
Whether MPL is solely to "blame" for compilation slowdowns people complain about when using boost I don't know, but it stands to reason that the more native language features can be used instead of library based workarounds and the less "redundant" code the compiler has to churn through, the more efficient the code becomes to compile. I've also read that microsofts STL tries to port as much of their code from tag dispatch to if constexpr, because it supposedly inicreases throughput, but I'm not aware of any benchmarks I could compare it with.
- Obviously a c++03 lib can't use std::chrono::duration or std::string_view in its interface. The former can sometimes be added as additional overload if available, however, adding the latter almost certainly leads to ambiguous overload resolution situations. So instead I have to convert the c++11/17/20 types into the appropriate boost types.
I think this is valid. But you are certainly allowed to create a PR for a Boost library which changes its use of a Boost type to its C++ standard library equivalent, with the proviso that the Boost library's base C++ level be C++11 and not C++03. The latter should not be an issue since Boost has already stated that Boost officially supports C++11 on up.
Aside from the fact that things like std::stng_view, std::byte or std::memory_resource aren't c++11, but c++17: Could you point me to this statement?
What statement ? Boost doesn't officially support C++03, even if individual libraries still support C++03, so a PR that changes a library that currently supports C++03 as its base level to instead support C++11 as its base level by using C++11 standard libraries in its code instead of the Boost equivalent libraries, would not be a radical change. Of course it is still up to the maintainer(s) of the library to accept the PR. As for changing a library's base level to C++14, C++17, or C++20 via a PR that probably needs to be justified since it would remove that library's usefulness for those compiling at the C++11 level.
All I'm aware of is that there is consensus that boost libs are allowed to drop c++03 support if they want - provided they follow certain procedure. So far I'm aware of 3 libs that are planning to make use of this: Math, Multiprecision and Geometry. I guess there are more, but I didn't get the impression that there is hughe push towards this.
Again: I'm not trying to tell anyone what is best for boost or the boost users because I'm lacking expertise, also can't really quantify any of it and am probably not the one who has pay the costs. But there are imho very reasonable reasons why people ask for a version of boost that makes use of c++XX beyond "because it is cool".