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/