Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-14 12:10:34
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
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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk