There are a couple of reasons to switch over to std::shared_ptr:
- You remove a dependency on Boost.
- Debuggers. Depending on your compiler and debugger, the debugger may be “smart” about
std::shared_ptrand show the pointed to object directly, where it wouldn’t for say, boost’s implementation. At least in Visual Studio,std::shared_ptrlooks like a plain pointer in the debugger, whileboost::shared_ptrexposes a bunch of boost’s innards. - Other new features defined in your linked question.
You get an implementation which is almost guaranteed to be move-semantics enabled, which might save a few refcount modifications. (Theoretically — I’ve not tested this myself)As of 2014-07-22 at least,boost::shared_ptrunderstands move semantics.(Actually I stand corrected. See this — the specialization for this is forstd::shared_ptrcorrectly usesdelete []on array types, whileboost::shared_ptrcauses undefined behavior in such cases (you must useshared_arrayor a custom deleter)unique_ptronly, notshared_ptr.)
And one major glaring reason not to:
- You’d be limiting yourself to C++11 compiler and standard library implementations.
Finally, you don’t really have to choose. (And if you’re targeting a specific compiler series (e.g. MSVC and GCC), you could easily extend this to use std::tr1::shared_ptr when available. Unfortunately there doesn’t seem to be a standard way to detect TR1 support)
#if __cplusplus > 199711L
#include <memory>
namespace MyProject
{
using std::shared_ptr;
}
#else
#include <boost/shared_ptr.hpp>
namespace MyProject
{
using boost::shared_ptr;
}
#endif