Re: [boost] Curiousity question

Subject: Re: [boost] Curiousity question
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-10-12 22:04:27

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

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.