Boost logo

Boost :

From: pbristow_at_[hidden]
Date: 2020-09-23 15:42:16


> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Rainer Deyke via Boost
> Sent: 23 September 2020 12:16
> To: boost_at_[hidden]
> Cc: Rainer Deyke <rdeyke_at_[hidden]>
> Subject: Re: [boost] Proposal for adding C++ level to the meta/libraries.json
>
> On 23.09.20 10:38, Paul A Bristow via Boost wrote:
> > Why not just give a *range of requirements* for example: "C++11 to C++17"?
>
> To me, that reads as "the library does not with C++20" or "the library is rendered obsolete by
C++20",
> not "the library has no features that C++20".

OK - I see the scope for confusion. How about

A *range of MINIMUM requirements* for example: "C++11 to C++17"?
 
> I'm actually very interested in when a library is rendered obsolete by a
> C++ standard. Lots of Boost libraries have equivalents in the C++
> standard library, or in some cases in the language itself. In some
> cases, the standard library component has completely rendered the Boost
> version obsolete. In some cases, the Boost version only exists as a
> backport of the standard library component, and was never intended to be
> used in C++ versions that include that component. In some cases, the
> Boost version and the standard library component have developed in
> different directions, and both are viable. And in some cases, the Boost
> version exists to correct a perceived flaw in a standard library
> component, so the Boost version should probably be preferred. It is
> often not clear which of these applies to which library, even after
> reading the library documentation (which may predate the standard
> library component).
>
> Some examples:
> - Boost.Assign looks like it has been rendered obsolete by
> std::initializer_list, but maybe it still has some functionality that
> std::initializer_list cannot handle?
> - Boost.Atomic: the short library description "C++11-style atomic<>"
> implies a backport of C++11 functionality to C++03, but I don't know if
> that's actually the case.
> - Boost.Variant[2]: I know that Boost.Variant predates std::variant,
> which in turn predates boost::variant2, but neither of these libraries
> provides a simple and clear explanation of how it differs from std::variant.

Doesn't (or shouldn't) all Boost libraries just redirect to use the standard library when
appropriate (without loss of features)?

This allows continued use by unfortunates stuck with VS 6 as well the luckier VS latest trackers.

I see this as a Boost USP.

Paul


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk