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 16:57:43

On 14 May 2015 at 13:34, Tom Kent wrote:

> > 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.
> >
> >
> I don't think this is even close to accurate. It is true that a bunch of
> the C++11 stuff boost had first, and is now redundant...and even more of
> the C++11 stuff was built into boost. However, all that isn't more than
> about 15% of what boost does.

This isn't the claim. The claim is that so long as the libraries in 
Boost which depend on STL11 equivalents cannot use the STL11 
equivalent, they are suffering from at least these problems:

1. An inability to easily interoperate with code which uses the STL11 
primitives e.g. std::future.

2. A compile time and binary bloat deficiency, sometimes very 
substantial.

3. A lack of sufficient maintenance, else the maintainer would have 
made use of STL11 available already just as Chris did with ASIO.

4. A potential deficiency in reliability and quality, as the STL11 
Boost equivalents are probably not as well tested, audited, and 
maintained as the STL11 editions simply due to resources invested.

This is why I claim that Boost 1.x is obsolete. I do not claim ASIO 
is obsolete. I do not claim any Boost library which uses or can use 
STL11 is obsolete, even if the code itself internally is ancient.

> > 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.
> >
> I agree that the monolithic nature is a big pain and the lack of
> maintenance is a bigger one, but I'm not sure that your solution is one
> that the majority of the current boost would ever make it into, if we even
> attempt to make a move like that.

If so, that's a good thing.

Me personally I'd have a "quality Boost" distro where the libraries 
supplied are only those with active maintainers OR no outstanding 
major defects are known on its bug tracker. I'd then supply a "legacy 
Boost" distro which is as the current distro is.

If a library gets chopped from the quality distro, that is a big red 
flag that a new maintainer is needed. We don't have such a big red 
flag mechanism right now. I don't doubt more maintainers would 
volunteer if the need for them were more obvious (BTW changes on this 
from the CMT are coming soon, so watch that space).

> I think we would be better served getting the more useful libraries
> outfitted with CI type testing (I really like the test matrix that is
> available on the AFIO page: https://github.com/BoostGSoC13/boost.afio) than
> trying to make a separate, modularized version of boost.

I'll be submitting a grant request to the SC to fund adding Travis 
and Appveyor support to all Boost libraries such that every commit 
and pull request gets instant notification if it compiles on OS X, 
Linux and Windows. If it doesn't compile, pull requests would be 
rejected until it does.

It's still a long way from the AFIO test dashboard, but it's an 
excellent first step. And I'm going to attempt a web service 
dashboard in new portable .NET in the next few months, but no 
promises.

> However, if the group does decide to make a new version where the libraries
> are modularized, then I would like to suggest that we come up with a new
> name instead of Boost 2.0, still under the Boost organization umbrella. I
> think the changes suggested go far beyond a simple version revision.

By Boost 2.0 I mean it like Web 2.0. I am currently unsure if any 
such Boost 2.0 would even have regular releases with version numbers, 
especially if a CI test solver simply spits out a known working 
across all libraries latest version with a date.

That said, one might stick with version numbers anyway to help 
downstream distros. That's a future decision I think not important 
now.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/