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

I would like to enable support for C++0x in GCC with -std=c++0x. I don't absolutely necessarily need any of the currently supported C++11 features in GCC 4.5 (and soon 4.6), but I would like to start getting used to them. For example, in a few places where I use iterators, an auto type would be useful.

But again, I don't need any of the currently supported features. The goal here is to encourage me to incorporate the features of the new standard into my programming "vocabulary".

From what you know of the C++11 support, is it a good idea to enable it in GCC, and then embrace it by, for example, switching from using boost::shared_ptr to std::shared_ptr exclusively as the two don't mix?

PS: I'm aware of this good question which compares the different flavors of shared_ptr but I'm asking a higher level advice on which to use before the standard is finalized. Another way of putting that is, when a compiler like GCC says it supports an "experimental feature", does that mean I am likely to encounter weird errors during compilation that will be major time sinks and a source of cryptic questions on StackOverflow?

Edit: I decided to switch back from std::shared_ptr because I just don't trust its support in GCC 4.5 as shown by example in this question.

Solution 1:

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

Solution 2:

I suppose it depends how much you use boost. I personally only use it very sparingly (in fact the random number library, in a single project). I've recently started using -std=c++0x for my other projects, and I use the new std:: library features like shared_ptr in them. I like my projects to have the minimum of dependencies, so I'd rather be dependent on the compiler's standard library implementation than on boost.

But I don't think there is a one-size-fits-all answer to this question.

Solution 3:

You should always use std::shared_ptr wherever possible, if it's available, instead of boost. This is basically because all new interfaces which use shared_ptr will use the Standard shared ptr.