On 6/2/2016 5:40 PM, Vicente J. Botet Escriba wrote:

Le 02/06/2016 à 20:55, Edward Diener a écrit :

...

I have finished all the main work on the Cxx dual library at https://github.com/eldiener/cxx_dual. The library is also in the Boost Library Incubator at http://rrsd.com/blincubator.com/bi_library/cxx_dual-2/?gform_post_id=1597.

The Cxx dual library, or CXXD for short, is a C++ macro header-only library which chooses between using a Boost library or its C++ standard equivalent library for a number of different C++ implementations, while using the same code to program either choice. An 'implementation' is a Boost library which has a C++ standard library equivalent whose public interfaces are nearly the same in both cases. An 'implementation' is called a 'dual library' in this documentation, or 'CXXD-mod' for short.

The library does this by defining object-like macros for including the appropriate header file and namespace or using either the Boost library version or the C++ standard library version of a particular dual library. CXXD currently supports twenty eight different dual libraries, where the Boost version and the C++ standard version is nearly interchangeable in some respects. CXXD also provides a macro-based solution for distinguishing between the Boost version and the C++ standard version of a dual library so that specific code for a particular dual library choice may be written in those cases where the public interfaces diverge.

The library came out of my initial PR to add such a feature to Boost.Config, and then I decided to create a separate library and expand on the functionality. The gist of the library is to write a single set of code for a particular implementation and have it work whether or not that code targets a Boost implementation or its C++ standard equivalent. The default algorithm will choose the C++ standard implementation if it is available, otherwise it chooses the Boost implementation. The default can be overriden for any of the 28 different implementations which CXXD supports.

With all the talk about supporting C++11 or C++14 in new code, the library offers a way of supporting C++11 or C++14 standard libraries if available whether one writes in C++03 dialect or uses the new language features of C++11 on up. The Cxx dual library itself, being macro based, should work with any C++ code at that code's language level. The library itself is NOT, repeat NOT, an attempt to enforce a C++ language level for anybody who wants to use it.

I have a little more work I am doing on increasing the support for Boost Build in the library, but all the central implementation of the library is complete in my mind.

Questions, comments, or bug reports are always welcome, either here in this mailing list, in the Boost Library Incubator, or as Github issues, by those who are interested in trying the library out or reading the documentation.

I will be using CXXD in another library on which I am working but hopefully others will find a use for it in their own code. Hi,

Thanks for working on this.

I have some questions.

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

* IIUC, the interface of the library is either one of the dual libraries, that is besides the macros, the the dual library doesn't document a specific interface, so the user must know both interfaces and its differences, isn't it?

There may be differences in the interface between the Boost version and the C++ standard version of a dual library. But you are correct that it is up to the end-user to know the difference if it would occur in his code. When differences do occur the end-user can use a dual library's CXXD_HAS_STD_'XXX' macro for an xxx implementation to code differently depending on whether the C++ standard library implementation has been chosen or the Boost implemntation has been chosen, without worrying about which one has been chosen. I agree it might be helpful for CXXD to try to understand any differences and try to smooth them over internally by the use of individual additional dual library specific macros or other mechanisms. But that would involve a great deal of extra work addressing each dual library. For the most part the dual libraries supported are very similar in a large part of their functionality. Where differences occur it is because one one side or the other a large set of additions have been made whereas on the other side those additions don't exist at all. In those sort of cases CXXD really can't do anything to smooth over differences. As an example Boost type_traits supports operator traits which are completely absent from the the C++ standard type_traits. As another example the C++ standard atomic implementation contains operations on atomic types as function templates which do not exist at all in Boost atomic. Nonetheless there is still plenty enough in common in both dual libraries that make using them with CXXD viable. For your interest there were some cases where Boost and the C++ standard library had the same name and idea for an implementation but the syntaxes were just too different so that I did not try to implement a dual library for it. An example of this is 'enable_if'. If I do take your suggestion of creating extra macros to smooth over the syntactical differences I might be able to create a dual library for 'enable_if' so that the smae code can refer to whichever one is chosen. But I wonder if the extra work in doing this would be worth it. Furthermore I do like the regularity of CXXD and to create extra macros for a particular dual library ruins that regularity to an extent.

* 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 am not as afraid of macros as you appear to be. I am aware generally of the technique of importing definitions from similar libraries into a common namespace and then using that namespace to refer to constructs, but I do not see what that buys you that the CCXD namespace macros doesn't give you for each dual library without all that work. Furthermore each time new common functionality is added to both sides of a dual library you have to add it to whatever you were importing, while CXXD doesn't have to do anything.

I have addressed this problem from a different perspective (See https://github.com/boostorg/thread/tree/develop/include/boost/thread/csbl). What do you think of this approach?

I will look at it. Thanks for your reply and interest in CXXD.

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 have finished all the main work on the Cxx dual library at https://github.com/eldiener/cxx_dual. The library is also in the Boost Library Incubator at http://rrsd.com/blincubator.com/bi_library/cxx_dual-2/?gform_post_id=1597.

The Cxx dual library, or CXXD for short, is a C++ macro header-only library which chooses between using a Boost library or its C++ standard equivalent library for a number of different C++ implementations, while using the same code to program either choice. An 'implementation' is a Boost library which has a C++ standard library equivalent whose public interfaces are nearly the same in both cases. An 'implementation' is called a 'dual library' in this documentation, or 'CXXD-mod' for short.

<snip> Hi,

Thanks for working on this.

I have some questions.

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

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

...

...

* IIUC, the interface of the library is either one of the dual libraries, that is besides the macros, the the dual library doesn't document a specific interface, so the user must know both interfaces and its differences, isn't it?

There may be differences in the interface between the Boost version and the C++ standard version of a dual library. But you are correct that it is up to the end-user to know the difference if it would occur in his code. When differences do occur the end-user can use a dual library's CXXD_HAS_STD_'XXX' macro for an xxx implementation to code differently depending on whether the C++ standard library implementation has been chosen or the Boost implemntation has been chosen, without worrying about which one has been chosen.

...

I agree it might be helpful for CXXD to try to understand any differences and try to smooth them over internally by the use of individual additional dual library specific macros or other mechanisms. But that would involve a great deal of extra work addressing each dual library. Right.

For the most part the dual libraries supported are very similar in a large part of their functionality. Where differences occur it is because one one side or the other a large set of additions have been made whereas on the other side those additions don't exist at all. In those sort of cases CXXD really can't do anything to smooth over differences. As an example Boost type_traits supports operator traits which are completely absent from the the C++ standard type_traits. As another example the C++ standard atomic implementation contains operations on atomic types as function templates which do not exist at all in Boost atomic. Nonetheless there is still plenty enough in common in both dual libraries that make using them with CXXD viable. I agree that there is a lot in common and that the differences would be

Thanks for confirming my guess. the exception. Sometimes however there are just some naming issues, i.e. see the optional in_place issue raised recently.

...

For your interest there were some cases where Boost and the C++ standard library had the same name and idea for an implementation but the syntaxes were just too different so that I did not try to implement a dual library for it. An example of this is 'enable_if'. If I do take your suggestion of creating extra macros to smooth over the syntactical differences I might be able to create a dual library for 'enable_if' so that the smae code can refer to whichever one is chosen. But I wonder if the extra work in doing this would be worth it. Furthermore I do like the regularity of CXXD and to create extra macros for a particular dual library ruins that regularity to an extent.

I'm not suggesting yes ( ;-) ) to add extra macros for this particular case even if the use of macros could solve also this kind of naming issues. Some kind of naming issues can be managed the CSBL (Common Standard Boost Library) approach I've taken without using macros. I reached to manage temporary some naming differences that have been solved now in Boost. See e.g. https://github.com/boostorg/thread/commit/80591fb64def1d1661f3fd4527b1e37e70...

...

...

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

...

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.

...

I am aware generally of the technique of importing definitions from similar libraries into a common namespace and then using that namespace to refer to constructs, but I do not see what that buys you that the CCXD namespace macros doesn't give you for each dual library without all that work. Furthermore each time new common functionality is added to both sides of a dual library you have to add it to whatever you were importing, while CXXD doesn't have to do anything. You are right. This means more maintenance and also more latitude, more freedom ;-)

...

I have addressed this problem from a different perspective (See https://github.com/boostorg/thread/tree/develop/include/boost/thread/csbl).

What do you think of this approach?

I will look at it.

...

Thanks for your reply and interest in CXXD. 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

There is not too much to look at as I have not needed the complete standard library. 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.

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.

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.

On 6/4/2016 9:28 PM, Rob Stewart wrote:

On June 4, 2016 2:01:25 PM EDT, Edward Diener <eldiener@tropicsoft.com> 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 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

...

...

...

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

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

Edward, you've missed that Vicente doesn't see that importing either a Boost or a Standard Library solution, into a common namespace requires anything more of the user.

The user would always use the new, common namespace name for something, regardless of its original namespace. For example, foo::x is the common name, but x may have been introduced into the foo namespace, by a using directive, from the boost or the std namespace.

In the end, the user always includes the foo header and uses the foo name. There are no macros in the user's code. Both solutions select one implementation or the other. Yours refers to the namespace of the selected implementation with a macro, while his just uses namespace foo.

It does involve more work and macros are still being used, although not to name the namespace. I honestly think that CXXD's solution is cleaner and more flexible. Lifting constructs which are normally accessed through one namespace to another namespace in that way seems to me a kludge. I am not sure of all the ramifications of doing this but I would be wary of doing such a thing myself. You also don't have the technique of overriding the dual library choice that you have with CXXD, unless you manually change some source, which you may not have access to in the first place. But if you think the CXXD macros are going to cause problems, just because they are macros and therefore "evil', by all means roll your own solution as Vicente has done.

On 6/5/2016 5:55 PM, Rob Stewart wrote:

On June 4, 2016 10:59:16 PM EDT, Edward Diener <eldiener@tropicsoft.com> wrote:

...

On 6/4/2016 9:28 PM, Rob Stewart wrote:

...

Edward, you've missed that Vicente doesn't see that importing either

a Boost or a Standard Library solution, into a common namespace requires anything more of the user.

...

The user would always use the new, common namespace name for

something, regardless of its original namespace. For example, foo::x is the common name, but x may have been introduced into the foo namespace, by a using directive, from the boost or the std namespace.

...

In the end, the user always includes the foo header and uses the foo

name. There are no macros in the user's code. Both solutions select one implementation or the other. Yours refers to the namespace of the selected implementation with a macro, while his just uses namespace foo.

It does involve more work and macros are still being used, although not

to name the namespace. I honestly think that CXXD's solution is cleaner

and more flexible. Lifting constructs which are normally accessed through one namespace to another namespace in that way seems to me a kludge. I am not sure of all the ramifications of doing this but I would be wary of doing such a thing myself.

You also don't have the technique of overriding the dual library choice

that you have with CXXD, unless you manually change some source, which you may not have access to in the first place. But if you think the CXXD macros are going to cause problems, just because they are macros and therefore "evil', by all means roll your own solution as Vicente has done.

See whether you still think so after reading my reply to Niall.

My thought is generally that CXXD represents the easiest approach and that importing either side of a dual library's namespace into another common namespace, no matter how it is controlled, does not represent anything better than what CXXD has to offer. Furthermore, although I haven't had the time or knowledge to work through all possible situations I believe that Vicente's approach could have problems involving customization points for a library, ADL, and/or template specializations. Vicente's approach is essentially changing the namespace in which constructs operate and any prior extensions to those constructs, in whichever side of the dual library is chosen, seem like they could be lost. The extensions will refer to a namespace in which the rest of the constructs are no longer operating or the extensions will be written in a namespace in which the rest of the constructs will no longer be operating. Either way I anticipate some C++ name lookup problems along the lines of using constructs in the common namespace no longer finding template specializations or extension points in a different namespace or referring, through ADL, to a different namespace. Of course I could be wrong about this and everything just "works" despite the different namespace in which all those constructs are now operating. But why deal with those possible problems in the first place. In CXXD the namespace stays the same and I think this is much safer. The fact that a simple object-like macro refers to the correct namespace at all times bothers me not at all simply because it is a macro.

On 6/6/2016 4:52 AM, Rob Stewart wrote:

On June 5, 2016 8:30:50 PM EDT, Edward Diener <eldiener@tropicsoft.com> wrote:

...

On 6/5/2016 5:55 PM, Rob Stewart wrote:

...

...

It does involve more work and macros are still being used, although

not

...

to name the namespace. I honestly think that CXXD's solution is cleaner and more flexible. Lifting constructs which are normally accessed through one namespace to another namespace in that way seems to me a kludge. I am not sure of all the ramifications of doing this but I would be wary of doing such a thing myself.

Vicente's approach, of I have it right, is pretty simple:

namespace boost { namespace something { using std::thread; // or (conditionally selected) using boost::thread; } }

With that, boost::something::thread is the name to use in the user's code.

The selection of what to import into the new namespace is managed by the preprocessor, so it can be overridden, too.

...

My thought is generally that CXXD represents the easiest approach and that importing either side of a dual library's namespace into another common namespace, no matter how it is controlled, does not represent anything better than what CXXD has to offer.

Allowing the user to just refer to boost::something::thread, rather than CXXD_THREAD::thread is less jarring to read, if nothing else. I don't think it offers much beyond that, though Vicente may have more information.

...

Furthermore, although I haven't had the time or knowledge to work through all possible situations I believe that Vicente's approach could have problems involving customization points for a library, ADL, and/or template specializations.

I don't think that's a problem for the library code itself and, since users are not generally permitted to open the std namespace, I don't think it would be a problem otherwise. Still, Vicente is best able to answer.

...

Of course I could be wrong about this and everything just "works" despite the different namespace in which all those constructs are now operating. But why deal with those possible problems in the first place.

If those are not problems, then there's nothing, real or imagined, to deal with.

...

In CXXD the namespace stays the same and I think this is much safer. The fact that a simple object-like macro refers to the correct namespace at all times bothers me not at all simply because it is a macro.

If the alternative works correctly, without exposing a macro to users, I suspect you'll have a much easier time with a review, and the burden on you doesn't seem much (any?) heavier.

We will have to agree to disagree.

On 6/6/2016 5:32 PM, Vicente J. Botet Escriba wrote:

Le 06/06/2016 à 12:59, Edward Diener a écrit :

...

On 6/6/2016 4:52 AM, Rob Stewart wrote:

...

On June 5, 2016 8:30:50 PM EDT, Edward Diener <eldiener@tropicsoft.com> wrote:

...

On 6/5/2016 5:55 PM, Rob Stewart wrote:

...

...

It does involve more work and macros are still being used, although

not

...

to name the namespace. I honestly think that CXXD's solution is cleaner and more flexible. Lifting constructs which are normally accessed through one namespace to another namespace in that way seems to me a kludge. I am not sure of all the ramifications of doing this but I would be wary of doing such a thing myself.

Vicente's approach, of I have it right, is pretty simple:

namespace boost { namespace something { using std::thread; // or (conditionally selected) using boost::thread; } }

With that, boost::something::thread is the name to use in the user's code.

The selection of what to import into the new namespace is managed by the preprocessor, so it can be overridden, too.

...

My thought is generally that CXXD represents the easiest approach and that importing either side of a dual library's namespace into another common namespace, no matter how it is controlled, does not represent anything better than what CXXD has to offer.

Allowing the user to just refer to boost::something::thread, rather than CXXD_THREAD::thread is less jarring to read, if nothing else. I don't think it offers much beyond that, though Vicente may have more information.

...

Furthermore, although I haven't had the time or knowledge to work through all possible situations I believe that Vicente's approach could have problems involving customization points for a library, ADL, and/or template specializations.

I don't think that's a problem for the library code itself and, since users are not generally permitted to open the std namespace, I don't think it would be a problem otherwise. Still, Vicente is best able to answer.

...

Of course I could be wrong about this and everything just "works" despite the different namespace in which all those constructs are now operating. But why deal with those possible problems in the first place.

If those are not problems, then there's nothing, real or imagined, to deal with.

...

In CXXD the namespace stays the same and I think this is much safer. The fact that a simple object-like macro refers to the correct namespace at all times bothers me not at all simply because it is a macro.

If the alternative works correctly, without exposing a macro to users, I suspect you'll have a much easier time with a review, and the burden on you doesn't seem much (any?) heavier.

We will have to agree to disagree.

I can not say yet if your approach is better or not. In order to say if it is better it should be compared and then we need the list of advantages and and liabilities of each approach.

I have given some limitation of the CXXD approach: * The fact that the name space is a macro is not the worst one for me and I can live with it if there is some additional advantage fro the user,

The advantage is that it works. The disadvantage of using a macro is in your own mind and other for whom using a simple distinctly named macro is some sort of a problem.

* Template specialization needs an additional macro in general (e.g. for Boost.Fusion). You have not fall in this case yet as maybe all the Boost libraries were in the boost namespace.

This is not true. You came up with a case involving Boost.Fusion, and I responded that Boost Fusion is not part of any dual library. From there you jump to the erroneous conclusion that specializations will not work with CXXD. In fact it is quite probable that specializations previously made for either side of a dual library will not work in your implementation since you are changing the name of the namespace and I am not.

* CXXD is unable to rename (e.g. enable_if versus enable_if_c). Well not exactly, but it needs to apply that is something equivalent to CSBL.

CXXD can rename things with another equivalent macro, if I chose to do that. I did not so choose since it is not needed. CXXD does have the current ability to rename macros which exist in both sides of a dual library. It is already done for the atomic implementation, which is the only dual implementation in which it is needed. The form is CXXD_XXX_MACRO for a given XXX implementation and it is documented in the CXXD docs. Clearly if I can use a macro to rename equivalent macros I can use a macro to rename equivalent, but syntactical different named, constructs. But I decided to avoid that because I did not want to create a dual library where the syntax for equivalent functionality was not the same and I did not want to create a one-off situation for particular dual libraries. A candidate for using specific CXXD macros for renaming equivalent functionality with different syntax in a potential dual library is 'enable_if' since the Boost names and the C++ standard names are different for the same basic 'enable_if' functionality ( look it up ). But I have resisted doing so. I may try to do so just to see what the reactions of others are, but given the dislike people have for using macros, despite the overwhelming success of Boost PP for Boost library authors, I don't anticipate that others will see the benefit.

* Documenting what the library exactly provides is almost impossible. It is up to the user to know exactly what is common between the dual libraries.

Documenting what the library provides is completely possible and has been done to the best of my ability. Documenting any differences between the same syntax possibly providing different functionality in any of the 28 different dual libraries is not a responsibility of CXXD as I see it. But I highly doubt that there are significant numbers of differences using the same syntax in the different dual libraries. That some side of a dual library sometimes has additional functionality compared to them other side I acknowledge. But that does not negate the usefulness of using the great amount of functionality in a dual library that is the same syntax and functions in the same way.

Importing approach should have also a lot of drawbacks and a tier person is often more critical to see them. * Possibly more maintenance, as you suggested. * Template specialization needs ALWAYS an additional macro in general. * Complexity: some possible issues that need to be confirmed. * Even if documentation could be more explicit it will be also difficult to say exactly what is the exact semantics of the proposed interface. Reducing the interface only to whatever match the standard would simplify the documentation.

I'm not sure I'm completely impartial.

I'm almost sure that your approach would have a better added value / cost ratio.

But people will be asking for more :( We can always say, no, this is out of the scope of the library.

Le 06/06/2016 à 10:52, Rob Stewart a écrit :

On June 5, 2016 8:30:50 PM EDT, Edward Diener <eldiener@tropicsoft.com> wrote:

...

On 6/5/2016 5:55 PM, Rob Stewart wrote:

...

...

It does involve more work and macros are still being used, although not to name the namespace. I honestly think that CXXD's solution is cleaner and more flexible. Lifting constructs which are normally accessed through one namespace to another namespace in that way seems to me a kludge. I am not sure of all the ramifications of doing this but I would be wary of doing such a thing myself. Vicente's approach, of I have it right, is pretty simple:

namespace boost { namespace something { using std::thread; // or (conditionally selected) using boost::thread; } }

With that, boost::something::thread is the name to use in the user's code.

The selection of what to import into the new namespace is managed by the preprocessor, so it can be overridden, too. Right.

...

My thought is generally that CXXD represents the easiest approach and that importing either side of a dual library's namespace into another common namespace, no matter how it is controlled, does not represent anything better than what CXXD has to offer. Allowing the user to just refer to boost::something::thread, rather than CXXD_THREAD::thread is less jarring to read, if nothing else. I don't think it offers much beyond that, though Vicente may have more information. Sometimes It allows to rename the minor differences. CXXD would be able to do that by adding a them to another namespace let me call it cxdd::xxx, import whatever is needed from boost and rename the minoir differences there. Then change the selected namespace for the macro.

...

Furthermore, although I haven't had the time or knowledge to work through all possible situations I believe that Vicente's approach could have problems involving customization points for a library, ADL, and/or template specializations. I don't think that's a problem for the library code itself and, since users are not generally permitted to open the std namespace, I don't think it would be a problem otherwise. Still, Vicente is best able to answer. Specialization are not permited in csbl namespace. This is why in both approached we need the additional macros I suggested for CXXD.

Best, Vicente

On June 5, 2016 3:47:42 AM EDT, Niall Douglas <s_sourceforge@nedprod.com> wrote:

On 4 Jun 2016 at 21:28, Rob Stewart wrote:

...

Edward, you've missed that Vicente doesn't see that importing either a Boost or a Standard Library solution, into a common namespace requires anything more of the user.

The user would always use the new, common namespace name for something, regardless of its original namespace. For example, foo::x is the common name, but x may have been introduced into the foo namespace, by a using directive, from the boost or the std namespace.

Do you mean an ultra-simplified

It was Vicente's idea.

form of what boost-lite does like this:

namespace boost { namespace afio { #if BOOST_AFIO_USING_BOOST_THREAD namespace stl11 = ::boost; #else namespace stl11 = ::std; #endif

#if BOOST_AFIO_USING_BOOST_FILESYSTEM namespace stl1z = ::boost; #else namespace stl1z = ::std; #endif } }

No, that wasn't what he was suggesting.

namespace boost { namespace afio { namespace stl { #if BOOST_AFIO_USING_BOOST_ATOMIC namespace atomic = ::boost; #else namespace atomic = ::std; #endif

#if BOOST_AFIO_USING_BOOST_THREAD namespace thread = ::boost; #else namespace thread = ::std; #endif

#if BOOST_AFIO_USING_BOOST_FILESYSTEM namespace filesystem = ::boost; #else namespace filesystem = ::std; #endif } } }

Now end user code must always write stl::<selector>::<class>. This I think would work well enough.

That also wasn't what he suggested.

I'll reiterate that boost-lite requires less typing on the end user and is much safer and less error prone to use than the above scheme.

Vicente's idea was to import, say, std::thread or boost::thread into a new, common namespace. That is, foo::thread might refer to either of the others, based upon platform support or even an override macro. ___ Rob (Sent from my portable computation engine)

On June 5, 2016 6:51:13 PM EDT, Niall Douglas <s_sourceforge@nedprod.com> wrote:

On 5 Jun 2016 at 17:53, Rob Stewart wrote:

...

Vicente's idea was to import, say, std::thread or boost::thread into a new, common namespace. That is, foo::thread might refer to either of the others, based upon platform support or even an override macro.

I'm sorry, I really don't understand how this is different from the code referred to above where boost::afio::stl::thread::thread would be exactly what you say.

If you meant you want to import exclusively and solely the boost::thread type alone, you could do:

namespace boost { namespace afio { namespace stl { typedef ::boost::thread thread; } } }

Is that what you meant?

I think his approach (I don't know why I'm spending so much time discussing someone else's idea of which I have only passing familiarity, but...) was the following: namespace boost { namespace something { using std::thread; // or (conditionally selected) using boost::thread; } } With that, boost::something::thread is the name to use in the user's code. ___ Rob (Sent from my portable computation engine)

On 6/4/2016 12:16 PM, Vicente J. Botet Escriba wrote:

Le 03/06/2016 à 18:46, Edward Diener a écrit : snipped...

...

...

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?

Do you mean: "* 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? I have addressed this problem from a different perspective (See https://github.com/boostorg/thread/tree/develop/include/boost/thread/csbl). What do you think of this approach?" I don't see any documentation regarding your perspective. Care to explain it ?

On 6/3/2016 5:53 PM, Gottlob Frege wrote:

On Thu, Jun 2, 2016 at 7:26 PM, Edward Diener <eldiener@tropicsoft.com> wrote:

...

On 6/2/2016 5:40 PM, Vicente J. Botet Escriba wrote:

...

Le 02/06/2016 à 20:55, Edward Diener a écrit :

...

I have finished all the main work on the Cxx dual library at https://github.com/eldiener/cxx_dual. The library is also in the Boost Library Incubator at

http://rrsd.com/blincubator.com/bi_library/cxx_dual-2/?gform_post_id=1597.

* 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 am not as afraid of macros as you appear to be.

Luke: I won't fail you. I'm not afraid. Yoda: You will be. You... will... be.

https://www.youtube.com/watch?v=TzmpXz5d2z0

Sorry, couldn't resist.

The bad guys in the star wars fantasies are children compared to the bad guys of human history or even of the imagination of the greatest of creative artists ( of which George Lucas doesn't even begin to qualify ). Sorry, couldn't resist.

Macros are evil.

Everyone to their own opinion <g>. Much boilerplate C++ code has been created in Boost libraries using the facilities of Boost PP. My won Boost VMD adds to that ability for those who are interested. C++ macros are like any other language facility, valuable if used correctly, poor if misused.

I'd appreciate more work from a library author if it meant less use of macros by the library users. Even when I'm the library author.

All CXXD does is just work ! I guess that must be evil. I do point out in the doc potential problems using a macro-based solution. But I found it the easiest way to achieve what I wanted to do with the least amount of work on the end-user's part, so I opt for it for myself. I only hope others will find it as useful.

On 6/3/2016 6:13 PM, Niall Douglas wrote:

On 2 Jun 2016 at 14:55, Edward Diener wrote:

...

I have finished all the main work on the Cxx dual library at https://github.com/eldiener/cxx_dual. The library is also in the Boost Library Incubator at http://rrsd.com/blincubator.com/bi_library/cxx_dual-2/?gform_post_id=1597.

Nice library Edward.

Thanks !

I'll remind the list of my non-macro alternative to this macro-based approach which has been in production use since 2014 and which I presented at C++ Now 2015. It can be found within https://github.com/ned14/boost-lite.

I could never understand your documentation or else I might have tried to compare CXXD to what you have done in my doc.

On 6/4/2016 9:15 AM, Niall Douglas wrote:

On 3 Jun 2016 at 20:18, Edward Diener wrote:

...

...

I'll remind the list of my non-macro alternative to this macro-based approach which has been in production use since 2014 and which I presented at C++ Now 2015. It can be found within https://github.com/ned14/boost-lite.

I could never understand your documentation or else I might have tried to compare CXXD to what you have done in my doc.

Is not the Readme on the front of the github for https://github.com/ned14/boost-lite not clear?

No, it is not clear to me how to use your library. Try putting yourself outside of your actual knowledge of what you are doing and try to think in practical terms of what the end-user would need to understand and know to use what you have created. Of course if you are just writing a library mainly for yourself with just some incidental documentation on what that functionality is all about then you are not that interested in having others consider your software for themselves unless they are willing to do a great deal of digging into the actual code to understand it. I am not willing to do that sort of digging. Maybe many others are, I really don't know.

If you do write a small program using both CXXD and boost-lite you'll surely notice the many APIs not covered by boost-lite e.g. all of <tuple>. My coverage is extremely conservative and incomplete to prevent interop surprises. My approach also only works for C++ 11 compilers, I deliberately exclude 03 usage so things like move construction don't surprise.

Nevertheless, it provides everything I need for my own libraries to dispense with the mandatory Boost dependency, which is its primary purpose. You're attempting something much more ambitious in CXXD.

You are correct about CXXD. My ambitions are for it to be used with any level of C++ and with any dual libraries where a great deal of the syntax and functionality are the same, without having to be a perfect match in all respects; and for it to be easy to use. if it is misused I don't think it will be because the documentation is lacking. At the same time I am very open to any improvements that can be made in CXXD within its scope of macro programming.