Re: [boost] Cxx dual library

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 
> https://github.com/eldiener/cxx_dual. The library is also in the Boost 
> Library Incubator at
> http://rrsd.com/blincubator.com/bi_library/cxx_dual-2/?gform_post_id=1597.

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 
https://github.com/ned14/boost-lite.

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 {

#if BOOST_AFIO_USE_BOOST_THREAD
  using namespace boost_lite::bind::boost::thread;
#else
  using namespace boost_lite::bind::std::thread;
#endif

}}}

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 
safety.

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/