Re: [boost] Cxx dual library

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

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

Vicente