Re: [boost] Curiousity question

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" An: boost@lists.boost.org 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 !