On 10/12/2016 7:17 PM, Stefan Seefeld wrote:
On 12.10.2016 18: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 !
At this point in time (with GCC 6.2 as my default compiler in my development environment), I'd use std::shared_ptr, and fall back to boost::shared_ptr for environments without C++11 support.
How would you fall back to support boost::shared_ptr ?
(In practice it's often the other way around. Consider Boost.Python: it has been supporting boost::shared_ptr for a long time, and I just now managed to add support for std::shared_ptr. I expect to eventually deprecate support for boost::shared_ptr, but that will still take a few years.)
So your interface(s) need to support both in the meantime ?