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.
Clear design and philosophical division between C++ 11 libs and 03 libs No evidence was presented for this. Arguing that future Boost
* 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. 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.