Re: [boost] Cxx dual library

Subject: Re: [boost] Cxx dual library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-06-04 12:16:00

Le 03/06/2016 à 18:46, Edward Diener a écrit :
> 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 :
>>>>>>
>>>>>>
>
>>>
>>>>
>>>> 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.
So
namespace CXXD_TUPLE_NS

will not wrok ;-)
>
>>>>>> * 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.
Ok. Now it is clear what the scope is (even if the scope includes in 
some way part of the solution). You have reached to put out my approach ;-)

Is this a library for end users or library authors?
>
>>>
>>>>> 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.
How my approach is worst for the users?
>
> I do not understand what you mean by:
>
> "Could you describe what the user need to do in addition?"
>
You said : "But when it involves a great deal of work on the end-user's 
part I think a macro-based solution is OK."
My approach don't request anything additional respect to a macro solution.
> 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.

I meant, what is the advantage for the user of the macro solution 
respect to the approach I suggested?

Vicente