Subject: Re: [boost] Cxx dual library
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-06-02 19:26:20
On 6/2/2016 5:40 PM, Vicente J. Botet Escriba wrote:
> Le 02/06/2016 à 20:55, Edward Diener a écrit :
>> 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
>> The Cxx dual library, or CXXD for short, is a C++ macro header-only
>> library which chooses between using a Boost library or its C++
>> standard equivalent library for a number of different C++
>> implementations, while using the same code to program either choice.
>> An 'implementation' is a Boost library which has a C++ standard
>> library equivalent whose public interfaces are nearly the same in both
>> cases. An 'implementation' is called a 'dual library' in this
>> documentation, or 'CXXD-mod' for short.
>> The library does this by defining object-like macros for including the
>> appropriate header file and namespace or using either the Boost
>> library version or the C++ standard library version of a particular
>> dual library. CXXD currently supports twenty eight different dual
>> libraries, where the Boost version and the C++ standard version is
>> nearly interchangeable in some respects. CXXD also provides a
>> macro-based solution for distinguishing between the Boost version and
>> the C++ standard version of a dual library so that specific code for a
>> particular dual library choice may be written in those cases where the
>> public interfaces diverge.
>> The library came out of my initial PR to add such a feature to
>> Boost.Config, and then I decided to create a separate library and
>> expand on the functionality. The gist of the library is to write a
>> single set of code for a particular implementation and have it work
>> whether or not that code targets a Boost implementation or its C++
>> standard equivalent. The default algorithm will choose the C++
>> standard implementation if it is available, otherwise it chooses the
>> Boost implementation. The default can be overriden for any of the 28
>> different implementations which CXXD supports.
>> With all the talk about supporting C++11 or C++14 in new code, the
>> library offers a way of supporting C++11 or C++14 standard libraries
>> if available whether one writes in C++03 dialect or uses the new
>> language features of C++11 on up. The Cxx dual library itself, being
>> macro based, should work with any C++ code at that code's language
>> level. The library itself is NOT, repeat NOT, an attempt to enforce a
>> C++ language level for anybody who wants to use it.
>> I have a little more work I am doing on increasing the support for
>> Boost Build in the library, but all the central implementation of the
>> library is complete in my mind.
>> Questions, comments, or bug reports are always welcome, either here in
>> this mailing list, in the Boost Library Incubator, or as Github
>> issues, by those who are interested in trying the library out or
>> reading the documentation.
>> I will be using CXXD in another library on which I am working but
>> hopefully others will find a use for it in their own code.
> Thanks for working on this.
> I have some questions.
> * Do you take in account template class specialization? if yes, could
> you point me where in the documentation is described how? is there an
> example? If not, would you mind to add some additional helper macros to
> make this possible without been able to do conditional compilation?
Do you mean specializing some class template that is part of the Boost
or C++ standard implementation of a dual library ? If so can you give an
example of where such specialization might be done and what it would
normally look like for any one side of a dual library supported by CXXD
? Maybe Boost 'thread' would be a good example which you could show me
since you are its present maintainer. That way if there are problems you
anticipate with it if used with CXXD, your code will illustrate what the
problems might be. CXXD always gives you the namespace of the dual
library chosen as CXXD_'XXX'_NS for implementation xxx. Would that
information not solve any class template specialization problems which
you anticipate ?
> * IIUC, the interface of the library is either one of the dual
> libraries, that is besides the macros, the the dual library doesn't
> document a specific interface, so the user must know both interfaces and
> its differences, isn't it?
There may be differences in the interface between the Boost version and
the C++ standard version of a dual library. But you are correct that it
is up to the end-user to know the difference if it would occur in his
code. When differences do occur the end-user can use a dual library's
CXXD_HAS_STD_'XXX' macro for an xxx implementation to code differently
depending on whether the C++ standard library implementation has been
chosen or the Boost implemntation has been chosen, without worrying
about which one has been chosen.
I agree it might be helpful for CXXD to try to understand any
differences and try to smooth them over internally by the use of
individual additional dual library specific macros or other mechanisms.
But that would involve a great deal of extra work addressing each dual
For the most part the dual libraries supported are very similar in a
large part of their functionality. Where differences occur it is because
one one side or the other a large set of additions have been made
whereas on the other side those additions don't exist at all. In those
sort of cases CXXD really can't do anything to smooth over differences.
As an example Boost type_traits supports operator traits which are
completely absent from the the C++ standard type_traits. As another
example the C++ standard atomic implementation contains operations on
atomic types as function templates which do not exist at all in Boost
atomic. Nonetheless there is still plenty enough in common in both dual
libraries that make using them with CXXD viable.
For your interest there were some cases where Boost and the C++ standard
library had the same name and idea for an implementation but the
syntaxes were just too different so that I did not try to implement a
dual library for it. An example of this is 'enable_if'. If I do take
your suggestion of creating extra macros to smooth over the syntactical
differences I might be able to create a dual library for 'enable_if' so
that the smae code can refer to whichever one is chosen. But I wonder if
the extra work in doing this would be worth it. Furthermore I do like
the regularity of CXXD and to create extra macros for a particular dual
library ruins that regularity to an extent.
> * Have you considered adding a new namespace and import the definitions
> from either boost or the standard library, so that the use of macros
> will be reduced and adding some non intrusive adaptation would be
No, because that leads to complications which are beyond the scope of
what I was trying to do. I am not as afraid of macros as you appear to
be. I am aware generally of the technique of importing definitions from
similar libraries into a common namespace and then using that namespace
to refer to constructs, but I do not see what that buys you that the
CCXD namespace macros doesn't give you for each dual library without all
that work. Furthermore each time new common functionality is added to
both sides of a dual library you have to add it to whatever you were
importing, while CXXD doesn't have to do anything.
> I have addressed this problem from a different perspective
> What do you think of this approach?
I will look at it.
Thanks for your reply and interest in CXXD.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk