Subject: Re: [boost] Cxx dual library
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-06-03 06:58:14
On 6/3/2016 1:54 AM, Vicente J. Botet Escriba wrote:
> 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?
Boost.Tuple.
Boost.Fusion is an excellent library but for CXXD's purpose there is no
C++ standard equivalent for it that would make turning Fusion into a
CXXD dual library viable.
>
> 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
#include <boost/cxx_dual/tuple.hpp>
#include CXXD_TUPLE_HEADER
struct MyClass {};
namespace CXXD_TUPLE_NS
{
template <>
struct tuple_size<X> : ....
}
>>>
>>> * 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 willing to listen to any suggestions for improvement that fall
within the scope of what CXXD is attempting to do.
>> 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 with you if the alternative solution is easy to use. But when it
involves a great deal of work on the end-user's part I think a
macro-based solution is OK.
>> 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.
Understood. The macro based approach has some downsides, which I have
attempted to address in my documentation. It's greatest strength,
however, is its simplicity and non-intrusiveness by which a programmer
can code for two very similar implementations. The need for doing that
is purely up to the programmer.