Boost logo

Boost :

Subject: Re: [boost] Boost Incubator Status Report
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-11-10 07:59:57

On 8 Nov 2014 at 17:01, Robert Ramey wrote:

> In my view, the single most effective Boost could do is to raise
> the standards for documentation of Boost libraries and help
> library authors meet these standards. This is a primary focus
> of the Boost Library Incubator. There's one big problem however.
> There isn't a strong consensus on what high quality C++ library is.
> I've tried to make the case for my viewpoint in the incubator
> (Advice, Concepts) And I think this has helped some - but still
> there are lots of people who I haven't yet been able to sway
> to my point of view. This is a work in progress.

As probably a leading disagreer with your vision here, I'll just
quickly update everyone on how my promised fork of Boost is going.

My vision for how to renovate Boost previously explained on this list
is that we need a ranked scoreboard of tightly focused domain
specific C++ libraries where the ranking is generated by automated
scripts which generate some form of quality score. This would
eliminate the need for any community reviews, to get your library
high into the ranked scoreboard you try your best to game the quality
score, and hopefully if the automated scripts are designed right you
should get some quality appearing in the resulting library.

The hard part is getting between here and there, and for that we need
actual truly modular Boost and not somewhat modular Boost only at the
git level. To that end, I started some months ago a local bindings
tool which uses the clang AST grok library to parse a C++ library and
output a set of bindings, plus some preprocessor programming to get
the C preprocessor to generate some unique namespacing.

All this lets you seamlessly "templatise" the dependent libraries of
a library, and moreover different "instantiations" of your library
with alternative dependencies can coexist happily in the same
Translation Unit (TU). I don't claim this solution is pretty, and
it's very heavily dependent on the preprocessor and on the compiler
coping with all the symbol aliasing, but it does work.

All this is great in theory, so what about practice? Well, two weeks
ago I started porting proposed Boost.AFIO from Boost to the local
bindings platform. It took about twenty hours of find in files regex
find and replace and a lot of work on the config.hpp setup to port
the library over, but now it's done AFIO now supports the following
configurations, all of which can coexist in the same TU:

* AFIO using Boost.Filesystem, Boost.ASIO, Boost.Test and
Boost.Build. i.e. the original configuration.

* Or, AFIO using any of the following variants in ANY combination:

1. Boost.Filesystem OR Filesystem TR as provided by VS14 CTP 4.

2. Boost.ASIO OR standalone ASIO OR Networking TR.

3. Boost.Test OR CATCH (BindLib provides an emulation of Boost.Test
using CATCH).

4. Boost.Build OR 100% header only everything, including
dependencies, i.e. NO build system at all.

This leads to the neato outcome that on VS14 CTP 4 I can compile the
entire of AFIO, including all unit tests, into a single executable
with a single cl.exe call on the command line, all without any trace
of Boost anywhere on the system. I can then execute all of those unit
tests by running the executable, and it "just works".

Total conversion time so far: about 30 hours. I would estimate
another 30 hours to go, but much of that will go on configuring the
Jenkins CI to regularly test every combination of the dependency
matrix above.

I'll present on all this work at C++ Now, but for now I would claim
that namespace binding has finally made dual use Boost libraries very
tractable. And with that comes the opportunity for truly modular
Boost libraries which are 100% header only and can be distributed as
such, and therefore makes possible the ranked scoreboard I want.

I think the ability for users to download a single, combined,
standalone header file which imposes no ABI consequences, is ABI safe
and requires no other dependencies including any choice of build
system is *my* vision of what will reinvigorate usage of Boost by
developers everywhere.


ned Productions Limited Consulting

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