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.
- 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. Do realize, however, that a number of Boost libraries which have C++11 on up standard library equivalents actually offer more functionality than their C++ standard library equivalent, and that the added functionality may be necessary for some other Boost library.
I'm naming just the two examples that are most relavant to me (I can think of a few more) but the point is: This is not about "having a warm feeling", but about the real costs for users that are a result from the continued support of c++03 and in particular the usage of boost types that have been "merged" into the standard library orthe language.
The difficult part is to place numbers on those costs and especially putting them in relation to the boost user base. It may very well be, that most of the people that are still using boost at all don't use more recent standards or that those costs are insigificantt to them and that the people complaining about the state of boost the loudest don't have any real interest in using boost anyway. Point in case: Almost all projects I'm involved in have removed their boost dependencies if they had any to begin with. So people like me might simply not be a relevant target audience for boost.
Best
Mike
PS And KISS applies? (Keep Is Simple Sirs)
There is a lot that can be said about boost but "simple" is certainly not something that comes to mind. Certainly not when we are talking about the implementation and - depending on the lib - not even when considering their usage.