Re: [boost] Cxx dual library

Subject: Re: [boost] Cxx dual library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-06-03 01:54:57

Le 03/06/2016 à 01:26, Edward Diener a écrit :
> 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.
>>>
>>> <snip>
>> 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 ?
>
I'm thinking of e.g. tuple_size<T>/tuple_element<I,T>. BTW, which boost 
tuple library is using CXXD? Boost.Tuple or Boost.Fusion?

I would expect the user to be able to do something like

struct MyClass {};

_CXXD_BEGIN_NAMESPACE_TUPLE

     template <>
     struct tuple_size<X> :  ....

_CXXD_END_NAMESPACE_TUPLE
>>
>> * 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.
>
Thanks for confirming my guess.
> 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.
Right.
>
> 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.
I agree that there is a lot in common and that the differences would be 
the exception. Sometimes however there are just some naming issues, i.e. 
see the optional in_place issue raised recently.
>
> 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.
I'm not suggesting yes ( ;-) ) to add extra macros for this particular 
case even if the use of macros could solve also this kind of naming issues.
Some kind of naming issues can be managed the CSBL  (Common Standard 
Boost Library) approach I've taken without using macros. I reached to 
manage temporary some naming differences that have been solved now in 
Boost. See e.g. 
https://github.com/boostorg/thread/commit/80591fb64def1d1661f3fd4527b1e37e706c5036

>
>>
>> * 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 can understand you and I believe that your library has its utility by 
its own. Just wondering how it could be improved for the end C++ user.
> I am not as afraid of macros as you appear to be.
I'm not afraid of macros. In general I prefer to don't use them when I 
can use an alternative solution.
> 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.
You are right. This means more maintenance and also more latitude, more 
freedom ;-)
>
>> 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.
>
There is not too much to look at as I have not needed the complete 
standard library.
> Thanks for your reply and interest in CXXD.
I would like to note that I'm not against your library, just I've taken 
a different approach and want to compare them and understand what are 
the advantages and liabilities for the end users and the maintainers.

Vicente