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: 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
> 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/