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 http://rrsd.com/blincubator.com/bi_library/cxx_dual-2/?gform_post_id=1597.
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. Hi,
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 library. 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 possible?
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 (See https://github.com/boostorg/thread/tree/develop/include/boost/thread/csbl). What do you think of this approach?
I will look at it. Thanks for your reply and interest in CXXD.