Boost logo

Boost :

Subject: Re: [boost] Cxx dual library
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-06-04 14:01:25


On 6/4/2016 12:16 PM, Vicente J. Botet Escriba wrote:
> 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 ;-)

Right. If I create a Boost fusion, C++ standard tuple dual library the
namespace macro would be probably 'CXXD_FUSION_NS', which would be set
to boost::fusion on the Boost side.

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

Both, if you mean that end-users are creators of executables. You can
use CXXD in header-only and non-header-only libraries or in executables.
I do discuss in the documentation the use of CXXD in libraries, and
particularly in the built portion of a non-header only library, as
separate from using it in an executable.

One thing on my to-do list is to create fairly simple example code for
use CXXD in each of these three scenarios.

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

I am sure I said that when an alternative involves a great deal of work
on the end-user's part I think a macro-based solution is OK. Please read
what I said again.

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

Let me look at your suggestion first and then I can compare them.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk