From: Gavin Lambert (boost_at_[hidden])
Date: 2020-09-24 02:57:03
On 23/09/2020 23:15, Rainer Deyke wrote:
> 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).
In theory, I think that's what the existing "std" field was for: "this
library is included in this standard version".
Although that's not the whole story, since e.g. Boost.Assign as you
mentioned was not directly included but (AFAIK) is rendered entirely
obsolete by initializer lists, and e.g. Boost.SmartPtr and Boost.Thread
while *mostly* obsolete do include some extended functionality not in
the standard implementation.
And Boost.Variant make different design choices from the standard
implementation, so all three are viable alternatives.
I don't think any meta field is really going to capture these sorts of
things too well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk