On 6/3/2016 3:27 PM, Michael Caisse wrote:

On 6/3/16 11:30, Edward Diener wrote:

...

On 6/3/2016 11:17 AM, Thomas Heller wrote:

<snip>

...

...

Personally, I'm not a big fan of such a solution, especially when those macros "leak" into the public interface. We had a similar interface which would automatically switch between std and boost function. The result looked nice at first sight, however the subtle differences between the two led to various problems, one of which was that documenting the public interfaces containing this macro was very difficult, where does it point to know? Where should we send users to who look for more information about this function type? Should they be aware of both? Switching compilers or even boost version and now suddenly everything seems broken? The solution for us was to just decide which one to use and go with it, setting the requirements to the used standard library/boost version as needed.

You are not being very specific about the problems you encountered, so it is really hard to respond to them.

Hi Edward -

I can provide an example why we don't allow this type of thing at Ciere and why I'm opposed to automatic selection of implementation in Boost libraries [1].

Years ago I had a problem with the is_pod type trait. MSVC and gcc were providing different answers in some situations. What I needed was consistency. The boost::is_pod was consistent. However, a boost::is_pod implementation that utilizes the vendor supplied implementation if there is one defeats my need for consistent behaviour.

I don't want Boost libraries making choices such as pulling in the vendor supplied implementation. If I wanted the vendor supplied implementation, I would have included it myself.

There are 28 different dual libraries in CXXD. You can decide to use CXXD for any one of those 28 different dual libraries, or not use it at all. CXXD does NOT force you to use any of the dual libraries in whi9ch you have no interest just to use CXXD for any one of them. Suppose you write a library and choose Boost.function and the end-user's of your library is using std::function all over the place. Do you feel good telling him that he has to convert his uses of the function implementation to accomodate you ?

michael

1. - Your proposed library is a bit different. Switching is the purpose of the library. It isn't a TR1-like Boost library that is switching implementation based on compiler availability.

CXXD is a library that is switching implementation based on availability. By default it chooses the C++ standard version if available of any dual library, but you camn override the default choice.

If I didn't want the switching behaviour I just wouldn't use the library. There might be a problem if other libraries are using CXXD and I (as a user of the other libraries) loose control of which implementation is being utilized.

That's why the override macros exist, so you can insist that a dual library implementation use the single implementation you want. Please read the doc to discover that. You don't "lose control".

On 6/4/2016 8:02 AM, Thomas Heller wrote:

Am 04.06.2016 1:17 nachm. schrieb "Bjorn Reese" :

...

On 06/03/2016 08:30 PM, Edward Diener wrote:

...

You are not being very specific about the problems you encountered, so it is really hard to respond to them.

http://www.boost.org/doc/html/move/emulation_limitations.html

Along that line, std::decay might not do what you expect.

I have no doubt there are occasional functional differences between a Boost library and its C++ standard equivalent even when the syntax is the same. if you are saying that CXXD by its nature hides those differences and therefore is problematic to use I can understand that point of view. I have made a note to discuss this in the documentation. I think this is very much similar to programmers using, let's say, the Boost type_traits library in their C++03 application and then deciding to compile using C++11 and switching to the C++ standard type traits library. Obviously they can continue to use Boost type_traits in their C++11 application but if they do decide to switch they have to look at what that entails. I do understand your argument that is safer to just choose using a Boost library or its C++ standard equivalent library in C++11 code and be done with it. But I also understand end-users being annoyed when some software library ( whether Boost or elsewhere ) is using the opposite dual library in their interfaces from what they are otherwise already using extensively in their own code.

On 6/4/2016 7:20 AM, Bjorn Reese wrote:

On 06/03/2016 08:30 PM, Edward Diener wrote:

...

You are not being very specific about the problems you encountered, so it is really hard to respond to them.

http://www.boost.org/doc/html/move/emulation_limitations.html

I am aware that both sides of a dual library, like 'move', may be different in some respects. That doesn't invalidate using CXXD for functionality that is syntactically the same and functionally the same. I did mention a number of times in the CXXD doc that CXXD_HAS_STD_XXX, for dual library xxx, can be used by end-users of CXXD to program any differences if necessary. I am not completely averse to using macro programming to smooth over any differences between both sides of a particular dual library, if it can be done. Obviously any dual library header file can be updated to do that but I would really like to keep any such one-off changes to a minimum.