Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries

Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries
From: Thomas Trummer (th.trummer_at_[hidden])
Date: 2015-05-14 04:57:52

I have a lot of problems with all of this. The following is based
solely on the slides without having seen the talk, so take it with a
grain of salt:

* The talk isn’t really about future C++ libraries but to prove a
point. This isn’t an issue per se but I wish people would be upfront
instead of using bait and switch tactics.

* Two out of the five libraries used as evidence are from the same
author as the talk. That leaves only three.

> Everybody avoids Boost.Test
Are they really avoiding it or this is just a result of starting
outside of Boost and not being part of Boost yet. Using asserts is
more of a poor engineering practice than saying anything about
Boost.Test.

> Most avoid Boost.Build
Again. Are they really avoiding it or this is just a result of
starting outside of Boost and not being part of Boost yet. Getting
into Boost will result in using Boost.Build to be part of the whole
regression infrastructure. I’m pretty sure no library author would
object to that.

> Everybody tries to use as little Boost as possible
Are they really avoiding other Boost libraries because of some problem
or don’t they just require other libraries? From the descriptions of
the libraries that actually seems quit plausible.

> All the libraries reviewed are ivory towers
This is just repeating the same point. Boost libraries cover a lot of
different areas so some of them are self-contained others have lots of
dependencies. Though, everybody would probably agree that it’s better
to have Boost.Atomic than five libraries implementing it itself.

* The “Best C++ 11/14 Practices Handbook” has nothing to do with C++
(except one or two points). That doesn’t mean it’s wrong or bad but
it’s just software engineering in general.

> Clear design and philosophical division between C++ 11 libs and 03 libs
No evidence was presented for this. Arguing that future Boost
libraries, even if they are C++ 11 only, are not going to depend on
existing libraries is quite silly. I don’t see anyone object to use
Boost.Build when getting accepted into Boost. If libraries use
Boost.Test or not isn’t really an issue as long as the tests work with
the testing infrastructure.

> Obvious natural split for a C++11 only Boost 2.0
Obvious to whom? There will be libraries in the future that require
C++11. This doesn’t create a problem for anyone. Neither does it
require a split away from Boost.