On 14 May 2015 at 10:57, Thomas Trummer wrote:
* 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.
Bait and switch is a classic feature of C++ Now talks. It is a conference of experts presenting to experts. We're not here to attend tutorials. We're here to see something different to the other big C++ conferences around the world, and that's why all the experts keep coming back to Aspen. I submitted almost the same topic for CppCon, but it's totally different content. For CppCon it's just a set of taster code examples using the libraries, almost a workshop.
* Two out of the five libraries used as evidence are from the same author as the talk. That leaves only three.
Actually I looked at 15 libraries, 10 in detail. Indeed two are mine, and about five have code or ideas from me in them.
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.
Yes they are avoiding Boost.Test. The authors themselves may chime in here to confirm.
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.
Actually they do. They want to use cmake. Not Boost.Build. Again, the authors may chime in here to confirm.
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.
Boost 1.x is obsolete. It is obsolete because enough of Boost 1.x is now in the STL that you no longer need to use Boost 1.x. It's also monolithic, and has a long list of structural problems. About half its libraries are undermaintained or not maintained. Many of the new authors wish their code as far away from it as possible because of the code smell. Quite frankly, as STL implementations get ever better, they are now better maintained and are of higher quality than Boost. In the end, STLs have a ton of full time engineers tending to them, Boost does not. Again, authors may wish to chime in or not themselves about their views on the matter.
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.
I've actually changed my talk in response to this.
* 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.
You might want to read it in detail instead of just the headings. It's very C++ specific, and fairly Boost specific. I give links of use examples throughout, all of which are to C++ projects or C++ code. Many of the tools proposed are C++ specific too.
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.
I have adjusted my presentation to clarify what I meant here. Thanks for the feedback. It was useful. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/