Boost logo

Boost :

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
>>>> 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.
>>>> <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.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 {};
> template <>
> struct tuple_size<X> : ....

#include <boost/cxx_dual/tuple.hpp>

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at