Boost logo

Boost :

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2020-05-25 10:06:55

> > 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 standard counterparts.
I think this is the point with using any dependencies: Is the added
value (in performance, features, ...) worth the cost (compile time
increase, maintaining compatibility, ...)
And as stated above: Using a stdlib part is not considered a dependency
by most.
> 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 already.
> 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.

There is no reason. The point of the proposal is to reduce dependencies
and hence "bloat" most users complain about. Boost.Atomic can stay
Boost03 and be fine. If it has features the std variant does not have
AND does not use other Boost libraries subsumed by the std then it would
even be considered part of Boost20

> The Microsoft STL is now open source (I'm sure you've all heard about
it), So in the case of Microsoft, it suffices to create a PR and
upstream the better boost library

Sadly not. It mustn't break ABI. Example: I proposed they implement the
never-valueless variant for cases where this is possible the same as
GCC/Clang do, but it was refused due to ABI. So good luck with

> User perceptions about bloat may be related to the download size.

It is also about compile times and binary size. Using MP11 over MPL
reduces the former, using std:: types over boost types (may) allow to
generate less code as template instantiations of the types in use are
also used in user code already. So using `std::optional<bool>` in user
code and `boost::optional<bool>` in boost internals or interfaces means
twice the code for the same functionality (unless references inside are
used of course)

> But I fear that (like other projects like Cmake) the BIG hurdle that
we struggle to get over, is *resources*.

This is the main point of the proposal: It is a gradual way. Lets say it
is "switch to C++11 - lite". No one is forced to do anything but
developers are incentivized to drop dependencies where possible and
there would be a way to measure progress. This can happen
Boy-Scout-Rule: Where you fix stuff, clean/update the surroundings.
Gradually you'll have a "clean"/updated library

> Tests and tests data are another area that many users rarely use, but
separately them would be a big task.

Sorry? Simply remove all test folders before uploading the tarball.
Done. For the tests-release: Simply remove all folders BUT the test
folder. The names are standard already so that is easy.

> Boost.MPL and Boost.Mp11 are very different in API, which means that
a library that uses template metaprogramming and wants to support C++03
and later cannot be compliant with the Epoch requirements, unless it
contains two versions of the TMP code

That is one of the points of the epoch proposal: MPL has known
shortcomings (mostly compiletime) that are "fixed" in a C++11 library
(MP11). So the authors/maintainers are incentivized to drop the MPL
dependency for MP11. if they don't because they care about C++03 (from
your statement above) for some reason, they (rightfully) don't get a
badge saying "Boost11". So what? No harm done except C++11 and up users
know the lib uses some old/slow dependency and can decide to not use it
if they don't deem this useful enough to offset the cost (see top)

Boost list run by bdawes at, gregod at, cpdaniel at, john at