From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-05-23 11:24:40
On 2020-05-23 12:56, Joaquin M LÃ³pez MuÃ±oz via Boost wrote:
> Prompted by general feelings about Boost perceived lack of modernization
> and internal "bloat",
> and after an explicit survey on what users dislike about Boost , I
> decided to try and write a more
> or less fleshed out proposal for an epoch-based organization of Boost
> libraries. I've extensively
> tested and refined the proposal during discussions on Reddit and the
> Boost Slack channel,
> and I feel this is now ready for presentation at the mailing list:
> I hope the proposal can start a productive conversation. Looking forward
> to your feedback.
From the article:
> if you were writing a new candidate Boost library with C++11 as its
baseline, would you strive to use std components rather than their Boost
counterparts, no matter how good the latter are? I would say you would.
I would not. As a user (either in-Boost or external) I would choose the
library that is technically better. Boost.Regex is actually a very good
example of such, as it is considerably faster than at least some popular
std::regex implementations. There are other examples where Boost
equivalents are technically better in one regard or another than the
I do not think discouraging use of (better) Boost libraries just because
there is a counterpart in the standard library is a good idea. Using the
best available tool should be a welcome choice on Boost developers side.
Next, I disagree with the idea that a library could be "not allowed to
progress". Why block further improvements and extensions? Take
Boost.Atomic or Boost.FileSystem, for example. These libraries are not
equivalent to the standard counterparts, and offer extensions that are
useful in practice and cannot be efficiently implemented "on top" of the
standard components. What would be the point of a Boost.Atomic v2 if it
had to reimplement Boost.Atomic? We are spreading our time thin as it is
The above examples are not an exception. I think, almost every library
that was adopted by the standard is not equivalent to the standard
component. Some of them have continued to evolve since adoption, and
results of this evolution may be adopted by the standard in the future.
I see no point in creating new versions of such libraries on each
iteration of such adoption.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk