Re: The new Boost 17.0.0

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-11-28 17:32:22

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" <boost_at_[hidden]>
>>
>>
>> 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.