Re: [boost] Cxx dual library

Subject: Re: [boost] Cxx dual library
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-06-03 12:46:28

On 6/3/2016 11:51 AM, Vicente J. Botet Escriba wrote:
> Le 03/06/2016 à 12:58, Edward Diener a écrit :
>> 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 :
>>>>>
>>>>>
>>>>> * 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.
> Boost.Fusion contains a more compliant implementation of std::tuple. If
> I remember correctly Boost.TR1 was using it.

I will look into it. Thanks !

>>
>>>
>>> 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> :  ....
>> }
>>
> This works only if  the namespace of tuple is boost, but not if it is
> nested, e.g. boost::fusion.

I would create a separate dual library for a separate namespace. If I 
were to create a dual library for fusion it would, on the Boost side, 
have 'boost::fusion' as its own namespace.

>>>>> * 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.
> Could you define the goal of the library and what ii the scope? To be
> clear, I'm not asking for the solution.

The goal is to be able to use the same syntax to program either a Boost 
implementation or its C++ standard equivalent. That way, depending on 
whether or not the compiler supports the C++ standard equivalent or not, 
the code will still work. Its scope is to provide a common solution for 
this problem for a multitude of different implementations without being 
greatly intrusive and without requiring extensive and ongoing 
re-engineering.

>>
>>>> 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.
> There is no more work on the user's side but on the developer's side.
> And for the user it is better to don't use macros as far as possible.
> Could you describe what the user need to do in addition?

I do not agree with a blanket statement of:

"And for the user it is better to don't use macros as far as possible."

It is only better to not use macros when an equally viable and easy to 
use solution is available.

I do not understand what you mean by:

"Could you describe what the user need to do in addition?"

The entire doc for CXXD explains how the user uses the library.

>>
>>>
>>> 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.
>>
> I understand the advantage for the developer, but not for the user.
> Could you elaborate about the non-intrusiveness by ....?

The user does not have to go to any elaborate means to use the 
functionality of the library as far as changing any code in the Boost 
implementation or C++ standard implementation of a dual library. Yes, of 
course, the user has to use the constructs of CXXD to program so that 
the Boost or C++ standard implementation of the library is being used, 
instead of directly using a particular implementation of a dual library. 
But for each dual library supported this means the same set of fairly 
small changes.

For dual library 'xxx':

1) Include the dual library header file, as in:
#include <boost/cxx_dual/XXX.hpp

2) Include the appropriate dual library macro header file:
#include CXXD_XXX_HEADER

instead of:

#include <boost/xxx/xxx.hpp>

or

#include <standard_library_xxx>

3) Use CXXD_XXX_NS::some_xxx_construct in the code

instead of:

boost::xxx::some_xxx_construct

or

std::some_xxx_construct

That's really it, for the most part.

It is really easy to switch between using a Boost implementation or C++ 
standard implementation to a dual library implementation of a supported 
dual library.

With that said I fully understand that programmers will decide to use a 
specific Boost library or a specific C++ standard library equivalent in 
their own code. But we Boost developers are creating libraries for 
others to use and when we hard code the equivalent dual library, and 
end-users using our Boost library are using the opposite equivalent dual 
library, I can understand those end-users being annoyed because they 
have to now accomodate a portion of their code to our use. CXXD was 
meant to solve that problem.