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.