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/