|
Boost : |
Subject: Re: [boost] Curiousity question
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-10-13 10:00:06
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk