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