Should I switch from using boost::shared_ptr to std::shared_ptr?

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_ptr and show the pointed to object directly, where it wouldn’t for say, boost’s implementation. At least in Visual Studio, std::shared_ptr looks like a plain pointer in the debugger, while boost::shared_ptr exposes 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_ptr understands move semantics.
  • std::shared_ptr correctly uses delete [] on array types, while boost::shared_ptr causes undefined behavior in such cases (you must use shared_array or a custom deleter) (Actually I stand corrected. See this — the specialization for this is for unique_ptr only, not shared_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

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)