Should I switch from using boost::shared_ptr to std::shared_ptr?
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, whileboost::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. -
(Actually I stand corrected. See this -- the specialization for this is forstd::shared_ptr
correctly usesdelete []
on array types, whileboost::shared_ptr
causes undefined behavior in such cases (you must useshared_array
or a custom deleter)unique_ptr
only, 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
Solution 2
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.
Solution 3
It's probably not a bad idea to start getting into the habit of using std::shared_ptr when allowed by the compiler. Since the interface is the same as boost's shared_ptr you can always switch back if you needed to.
Solution 4
Another reason to switch over to std::shared_ptr
:
it supports std::unique_ptr
, i.e. has constructor.
boost::shared_ptr
doesn't.
Solution 5
If you are just building on the one platform that is fine (make the switch)
(Note: You do have unit tests to validate backward compatibility don't you?)
If you compile on multiple platforms is where it becomes a little more awkward as you need to validate that the features on g++ 4.5 are available on all the platforms you use (ie building for MAC/Linux the default Mac g++ compiler is still a couple of version's behind the default compilers on Linux).
Alan Turing
Updated on July 09, 2022Comments
-
Alan Turing almost 2 years
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, anauto
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
tostd::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. -
GManNickG almost 11 years
typedef shared_ptr std::shared_ptr
? -
Billy ONeal almost 11 years@GManNickG: lol. Good catch. Damn typedef working backwards! (It feels like an assignment to me)
-
Billy ONeal almost 11 years@GManNickG: Hmm... looking back at this maybe a using statement would be better. What do you think?
-
GManNickG almost 11 yearsYeah, a template
using
is correct:template <typename T> using shared_ptr = std::shared_ptr<T>;
. The problem is that this is a C++11 feature, so you can't use it in theboost::shared_ptr
case. :) The C++03 way is another type with an internal typedef. -
Billy ONeal almost 11 years@GMan: you can't just do "using std::shared_ptr;", and bring that name into that namespace?
-
GManNickG almost 11 yearsIf you want to keep things simple, sure. :)
-
Billy ONeal almost 11 years@GManNickG: Better? (Sorry, I don't have a boost installation to make sure this works with)
-
BenC almost 11 yearsIt may also be useful to add the same kind of support for
std::make_shared
/boost::make_shared
. -
andreas buykx almost 6 yearsI was surprised to see that the cases with malloc and new were so much faster. I don't think anyone would want to use the smart pointers if the performance penalty was a 10x slower call. Your test cases are not comparable: 1. malloc and new are only called once, allocating an array of size LENGTH, whereas in all other cases allocations are done LENGTH times, 2. for malloc and new you assign the result of rand to the allocated array, whereas in all other cases the result of the allocation being pushed back into a vector, leading to further memory allocations/reallocations.
-
andreas buykx almost 6 yearsAs a side note: pie charts are not a very useful way to show this kind of data. This article tells you why ... perceptualedge.com/articles/visual_business_intelligence/…