Re: [boost] Curiousity question

Subject: Re: [boost] Curiousity question
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-10-12 21:09:56

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