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: Tom Kent (lists_at_[hidden])
Date: 2015-05-14 14:34:27

On Thu, May 14, 2015 at 11:10 AM, Niall Douglas <s_sourceforge_at_[hidden]>
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.

Myself (as an end-user), I use python, test, interprocess, lexical_cast,
date_time, filesystem, program_options, uuid and more...none of which are
available in C++11, and most of those have no aspirations of being in any
future standard.

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

As and end user, I'd love to have a modular install, where just the
libraries I need and their dependencies are installed. However, the more I
think about it, it doesn't seem like that would be simple...the
dependencies of the more useful libraries are (correctly) quite numerous.
This makes sense, they are trying to do complicated things, so they take
advantage of existing functionality to lower their own complexity....that
is far better than trying to re-write existing stuff just to keep the
dependency list down.

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.

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.

Tom