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. :) 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 <boost/atomic.hpp> namespace my_atomic { using boost::atomic; } #elif some_fallback_is_available ... some custom implementation ... #else #error Cannot find an atomic implementation. #endif 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. 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.) 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.
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).