Boost logo

Boost :

Subject: [boost] Boost 2.0 ideas (was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's c
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-05-20 08:25:22

On 19 May 2016 at 8:36, Robert Ramey wrote:

> Given the above, I never understood what you're proposal was (actually
> is, because I still don't understand it).


1. New Boost 2.0 distribution with rebooted internals incompatible
with Boost 1.x. C++ 14 STL used by default.

2. Rebooted internals designed by a committee of the willing and with
a yay/nay vote of the usership of the final design. No arguments with
the plan from outside the committee, just yay/nay.

Niall's personal top ten ideas for rebooted internals (committee
decides after investigation of everyone's proposed options):

1. cmake build system throughout.

2. ctest test system throughout.

3. cdash reporting system throughout.

4. Niall's Boost 1.x compatibility shim layer (which he presented at
C++ Now 2015) allowing a single source code base to be part of Boost
1.x and 2.x simultaneously. Library maintainers decide to opt into
the shim, or not.

(4a. Even if not using compatibility shim, all Boost 2.0 libraries
version their ABI and API. Some libraries may optionally enforce ABI
compliance using that tool)

5. New documentation system based on doxygen comments somehow.

6. New online single header generation facility so you tick the Boost
2.0 libraries you want and it spits out a single drop in header file.

7. Built in edge execution coverage testing and fuzz testing using
Niall's fancy new LLVM based automated kernel test infrastructure
he's currently working on for presentation in 2017 (it's not written
yet, but looking seriously cool).

8. clang AST based enforcement of Boost coding guidelines.

9. All Boost 2.x libraries to be C++ Modules

10. There is no longer any Boost 2.x distribution as a ZIP archive.
Instead all contributors to Boost 2.x libraries are required to use
cryptographically signed git commits and tags. We push distribution
onto the online distro generator and onto github and dispense with
official releases entirely in favour of cryptographically signed tags
meaning "this is known to work well" as defined by Travis + Appveyor
running a deep suite of unit, integration and functional tests.

I have more items if I were to trawl my notes. Those just came to the
top of my head.


ned Productions Limited Consulting

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