Re: [boost] Curiousity question

Subject: Re: [boost] Curiousity question
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-10-13 10:33:21

On 10/13/2016 10:00 AM, Andrey Semashev wrote:
> On 10/13/16 16:38, Edward Diener wrote:
>> On 10/13/2016 5:14 AM, Andrey Semashev wrote:
>>> On 10/13/16 01:58, Edward Diener wrote:
>>>> I would like to ask a design question for any Boost developers or
>>>> anyone
>>>> on this mailing list who might care to answer.
>>>>
>>>> You are designing or working on a library, perhaps for Boost, perhaps
>>>> for fun, and part of the design of the library has some public
>>>> functionality taking a shared pointer as input. You:
>>>>
>>>> 1) Use boost::shared_ptr
>>>> 2) Use std::shared_ptr
>>>> 3) Use both boost::shared_ptr and std::shared_ptr with the same
>>>> functionality
>>>> 4) Use neither, you roll your own shared pointer-like functionality
>>>> 5) You don't lke shared pointers and use raw pointers instead
>>>>
>>>> I really am curious about this. I haven't put any limitation on your
>>>> library or made any presumption on who your library is for, on purpose.
>>>> Thanks for anyone answering !
>>>
>>> Depends on the target. If I can rely on C++11 features being available
>>> in the project then I use std::shared_ptr. Otherwise I use
>>> boost::shared_ptr. Both times unconditionally, i.e. no auto-detection
>>> stuff.
>>
>> What would you do if the target is determined the general end-user, who
>> may be compiling your library with whatever options he chooses with
>> whatever compiler he chooses in whatever OS he chooses ?
>
> There is always a list of supported targets. If that list includes a
> target without C++11 then I'll probably use boost::shared_ptr. That is
> what I'm doing in Boost.Log, which supports C++03.

I understand that and I think that is the general consensus. But what 
might happen, not that it seems to bother anyone much but me <g>, is 
that your library, which supports C++03, is nevertheless "compiled" by 
some programmer(s) using C++11 in their own project. Then their normal 
use of std::shared_ptr ( because it's there and naturally supported by 
their compiler implementation in C++11 mode ) doesn't really "play well" 
with your own use of boost::shared_ptr. Of course you may well say 
"what's the big deal, when you interface with my library you will use 
boost::shared_ptr and have a dependency on it, while otherwise you have 
chosen to use std::shared_ptr and have a dependency on your compiler's 
implementation. I see no problem with that." And technically you would 
be right, but practically the user of your library might feel 
differently about it.

>
> The choice is specific to a particular component, though. For instance,
> I tend to use Boost.Atomic even on C++11-enabled targets because I know
> it's potentially more efficient. I'm also reluctant to use
> std::condition_variable because I know some implementations have buggy
> timed functions.

Understood. One of the situations I discusses in my cxx_dual library, 
where a programmer provides a one-off override of his own use of a 
particular dual library, is based on exactly what you mention just 
above. I personally know for instance that the std::bind and std::ref 
implementations in VC++10 are broken, not that Microsoft will ever go 
back and fix them for a compiler that very few use anymore. My OP should 
have also posited that boost::shared_ptr and std::shared_ptr are presume 
to work equally flawlessly in my 'curiosity question".