Boost logo

Boost :

Subject: Re: [boost] Cxx dual library
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-06-03 18:13:42

On 2 Jun 2016 at 14:55, Edward Diener wrote:

> I have finished all the main work on the Cxx dual library at
> The library is also in the Boost
> Library Incubator at

Nice library Edward.

I'll remind the list of my non-macro alternative to this macro-based
approach which has been in production use since 2014 and which I
presented at C++ Now 2015. It can be found within

Usage might be like this:

#include "boost-lite/include/bind/stl11/boost/ratio"
#include "boost-lite/include/bind/stl11/std/ratio"
#include "boost-lite/include/boost/test/unit_test.hpp"
  // In this context use Boost's ratio
    using namespace boost_lite::bind::boost::ratio;
    using two_thirds = ratio<2, 3>;
    using one_sixth = ratio<1, 6>;
    BOOST_CHECK((ratio_less<one_sixth, two_thirds>::value));
  // In this context use STL11's ratio
    using namespace boost_lite::bind::std::ratio;
    using two_thirds = ratio<2, 3>;
    using one_sixth = ratio<1, 6>;
    BOOST_CHECK((ratio_less<one_sixth, two_thirds>::value));

Far more interesting is to have compile time macros select whether
your Boost library uses Boost or the C++ 11 standard library. This is
how my libraries do this:

namespace boost { namespace afio { namespace stl11 {

  using namespace boost_lite::bind::boost::thread;
  using namespace boost_lite::bind::std::thread;


AFIO always refers to (boost|std)::thread stuff via stl11::thread. It
"just works". I now have three libraries all using this approach,
Boost.Outcome, Boost.AFIO and Boost.KernelTest with two years of near
daily usage. I have encountered no problems at all.

Some differences of namespace binds as compared to Edward's macro
based approach:

1. Binds are only present for those items which are identical in
terms of ABI between Boost and the STL. If they vary in any way, they
aren't there, thus preventing surprises by giving a compile-time
error. A macro based approach cannot achieve a similar level of

2. As you saw in the example above, binds are namespaces and
therefore can be bound into contexts, functions or other namespaces
via normal C++. This avoids having to spatter your code with macros.

3. I have designed binds to also be C++ Modules i.e. they equal a C++
Modularisation of Boost. This is untested as yet, but it should just
need some cmake magic to make it work.

4. They also enable very fine ABI control. For example, if you don't
attempt to maintain a stable ABI in your library - say if you're a
header only library - it's very easy to permute your linkage with
your last git commit SHA, thus ensuring that every edition of your
library can safely coexist with any other edition of your library in
the same binary without collision. Equally, if you do offer a stable
ABI, that can be versioned and encoded with your dependencies *hard
bound* to a particular version. This particular feature enables
individual libraries to iterate without worrying about breaking
dependencies or sending ripples of breakage throughout a dependency
chain. Such a facility could help enable a collection of standards
aspiring libraries to scale out to far greater degree than Boost has
achieved to date.


ned Productions Limited Consulting

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