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.
So, we should use shared_ptr when we want to assign one raw pointer to multiple owners. // referring to the same managed object. When to use shared_ptr? Use shared_ptr if you want to share ownership of a resource.
In short: Use unique_ptr when you want a single pointer to an object that will be reclaimed when that single pointer is destroyed. Use shared_ptr when you want multiple pointers to the same resource.
boost::shared_ptr<> offers a certain level of thread safety. The reference count is manipulated in a thread safe manner (unless you configure boost to disable threading support). So you can copy a shared_ptr around and the ref_count is maintained correctly.
shared_ptr are noticeably slower than raw pointers. That's why they should only be used if you actually need shared ownership semantics. Otherwise, there are several other smart pointer types available. scoped_ptr and auto_ptr (C++03) or unique_ptr (C++0x) both have their uses.
There are a couple of reasons to switch over to std::shared_ptr
:
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.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)unique_ptr
only, not shared_ptr
.)And one major glaring reason not to:
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With