Re: The new Boost 17.0.0

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-11-29 21:43:57

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