Re: [boost] Curiousity question

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

On 10/13/2016 9:42 AM, Jens Weller wrote:
> Hi Edward,
>
> this interface seems to exist to ensure the lifetime of the object handed to my library,
> 5) is hence not the best option.
>
> I'd go with supporting both std::shared_ptr (default) and boost::shared_ptr in my library.

That could be much extra code to write if you are going to support both 
in every inteface you design in which either is normally being used.

>
> 4) would be an interesting option for purely generic code, just modeling the interface of the shared_ptr type, but not restricting it to a concrete type seems smart.
> One could still have std::shared_ptr as the default for the template argument.

That is an interesting idea. But I don't think it scales that well, 
considering that shared pointers themselves are created based on the 
type of pointers being used.

>
> boost::shared_ptr would be interesting as a way to support pre C++11 code.

I think that is what many people have said they do, If it is pre C++11 
they will use boost::shared_ptr and if it is C++11+ they will use 
std::shared_ptr. It is eminently reasonable.

But it could still lead to unhappiness for programmers using your 
library  compiling your pre-C++11 library using C++11 and 
std::shared_ptr; or for programmers compiling your C++11 library and 
still using boost::shared_ptr ( maybe because of a bad or missing C++11 
implementation of std::shared_ptr ).

>
> cheers,
>
> Jens Weller
>
>> Gesendet: Donnerstag, 13. Oktober 2016 um 00:58 Uhr
>> Von: "Edward Diener" <eldiener_at_[hidden]>
>> An: boost_at_[hidden]
>> Betreff: [boost] Curiousity question
>>
>> 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 !