Boost logo

Boost :

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

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

> 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


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at