The new Boost 17.0.0

From: Mike (mike.dev_at_[hidden])
Date: 2020-11-29 15:47:45

> 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? 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".

Best

Mike