Subject: [boost] Update on status of C++ 11 only Boost fork/modular distro
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-10-07 07:47:02
Dear all,
You may remember me saying these past six months that I was working
on the tools necessary to fork Boost into a C++ 11 only distro which
also lets you use Boost libraries individually standalone without the
rest of Boost.
I have got a first alpha version of my clang AST based local bindings
generator working, and you can see it at
https://github.com/ned14/local-bind-cpp-library. This tool lets you
generate a set of local namespace bindings for some implementation of
some library such that your library implementation code need not care
what the underlying implementation of dependent library facilities
is. This way your Boost library could be using either Boost or the
C++ 11 STL and you don't need to care (most of the time).
Now I have the first alpha version working and generating a
reasonable set of C++ 11 STL bindings
(https://github.com/ned14/local-bind-cpp-library/tree/master/include/s
tl11), I'll start with porting over my own Boost libraries to it, so
Spinlock, Expected, non-allocating future-promise and AFIO will be
the first, and with those AFIO should become capable of being
completely standalone from Boost whilst still also able to compile
against Boost.
After that I'll try porting the entire of Boost.Thread over such that
Boost.Thread no longer needs Boost. I think that would be hugely
useful for people wanting to use potential C++ 17 threading
functionality without needing to draw in all of Boost as a
dependency, and that might greatly widen the empirical experience new
threading facilities might get before the 17 standard.
Once I've succeeded with that, if the present situation with Boost
has not improved by then, I'll press ahead with a new Boost distro
website which score ranks Boost modules according to the scoring
manifest I outlined on this list some months ago, and lets you
download standalone Boost distros of your choice. Obviously only
libraries ported to be standalone capable would be available, so I
would hope that if I can demonstrate an easy port with Boost.Thread,
others may follow with their libraries.
All this work occurs in my free time of a few hours per week, so
progress will be slow but steady. Comments on the local namespace
binding tool are welcome. Comments on the proposed C++11/14 good
practice idiom of binding dependent library APIs into the local
namespace are also welcome, because as far as I can tell no one here
has discussed a formal set of conventions to make best use of inline
namespaces for new libraries. I'll put it another way - local
namespace binds are a poor man's version of Herb's proposed C++ ABI
facility. As much as they aren't quite as good, they are probably
good enough (relative to Herb's most recent proposal).
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/