On 10/12/2016 9:09 PM, Gavin Lambert wrote:
On 13/10/2016 13:24, Edward Diener wrote:
Are you assuming that programmers using your small library compiler with c++11 support ?
Mostly I'm writing apps, or libraries for use within my organisation, not really for public consumption. So based on the intended target app/environment I already know whether it supports C++11 or not and can pick accordingly.
Perhaps I'm not the intended audience of your question in that regard. :)
I was just asking as a general question to see what others do. Any answers regarding your choice is interesting and valuable to me.
Not so much with shared_ptr (since boost::shared_ptr is a reasonable default for the dual case anyway), but in some cases where something needs to be used in both environments I'll put in some custom redirection eg:
#if some_detection_magic #include <atomic> namespace my_atomic { using std::atomic; } #elif some_other_detection_magic #include
namespace my_atomic { using boost::atomic; } #elif some_fallback_is_available ... some custom implementation ... #else #error Cannot find an atomic implementation. #endif
Yes, this I understand. My cxx_dual library basically does the above but in a syntactically smoother manner, while assuming that the Boost side is always available so no "Cannot find an atomic implementation" will ever occur there.
And then my code will use only my_atomic::atomic instead. Obviously this is ABI incompatible whenever the magic detects differently, so it makes it harder to provide pre-built binaries, but it's great for source compatibility.
Understood.
In fact half the time I wonder if I should refactor code so that it never uses the std:: or boost:: namespaces directly and always import things into custom namespaces like this, such that it's trivial to swap out all uses of a given type with an alternate implementation, either from a separate library or with a custom wrapper. (Sometimes I have moments where I want to swap a custom allocator into all std::vectors, for example, which is easier if everything actually uses a custom typedef/alias.)
A namespace alias also works nicely. That's what cxx_dual uses. It's also much easier to encode into the process of dual implementations.
Haven't quite gone that far yet myself though, though I know that your cxx_dual library and Niall's similar library are along those lines.
The impetus for cxx_dual is that I was ( and still am ) working on a library where shared pointers and function callables are part of some public interfaces. So I was trying to decide, do I use boost::shared_ptr or std::shared_ptr, do I use boost::function or std::function ? And I had some answers, but whatever it was I felt I was sure to run into a potential end-user of my library who would feel, based on his compiler implementation, compiler support for C++11, compiler options, OS for which he was using my library, that whatever I chose would be wrong for him. Of course like most programmers I could simply say, these are my choices and if they don't correspond to what you are otherwise using if you use my library, it is up to you to adjust. My OP is an effort to see how other programmers involved with Boost think about this.
Otherwise, I'll use boost::shared_ptr, except where required to use std::shared_ptr by existing interfaces.
So if existing interfaces already used std::shared_ptr you'd keep them like that, else for any new shared pointer interfaces you would use boost::shared_ptr ?
If my code depends on something that uses std::shared_ptr then of course I'll use std::shared_ptr in the downwards-facing interfaces with that. But I will prefer boost::shared_ptr for any upwards-facing interfaces unless there's some compelling reason not to use it (such as not otherwise requiring a dependency on Boost).
The end-user of your library, especially if it is meant for public consumption, might find it odd <g> that some interfaces use std::shared_ptr and others use boost::shared_ptr. Even more so if he is using one or the other of the two consistently throughout his own usage of your library in whatever executable or library he is working on. But I understand why you would prefer your own way. As long as you document what should be used it is easy enough for the end-user of your library to adapt successfully.