Re: [boost] Cxx dual library

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