see “Count with me: how many smart pointer classes does Qt have?”
|QPointer<T>||Qt Object , guarded pointer,
set NULL after delete/deconstruction
However, pointed resource not released
|QSharedPointer||reference-counted strong sharing of pointers||Qt4.5|
|QWeakPointer||reference-counted weak sharing of pointers||Qt4.5|
|QSharedDataPointer||Qt (Implicit Sharing) copy-on-write||Qt4.0|
Introduction to smart pointers: http://en.wikipedia.org/wiki/Smart_pointer
|std::auto_ptr||Not recommended in C++11||C++03|
|std::weak_ptr||Intended for Garbage collection||C++11|
|std::unique_ptr||non-copyable, but can be transfered||C++11|
|boost::scoped_ptr<T>||Equal to QScopedPointer
neither copyable nor movable.
Qt unique pointer?
These QT/C++ smart pointers are exchangeable?
- These are not derived from QObject! QSharedPointer<T> is binary compatible with ordinary pointer. It should be possible to construct C++11 smart pointers.
is a weak pointer class and it shares the pointer value, not the data. It only operates on QObject and QObject-derived classes. This class was added in Qt 4.0
unique_ptr is neither copyable nor copy-assignable, so two instances of
unique_ptr cannot manage the same object. A non-const
unique_ptr can transfer the ownership of the managed object to another
unique_ptr. A const std::unique_ptr cannot be transferred, limiting the lifetime of the managed object to the scope in which the pointer was created. When the
unique_ptr is destroyed, it disposes of the object through
Typical uses of
- providing exception safety to classes and functions that handle objects with dynamic lifetime, by guaranteeing deletion on both normal exit and exit through exception
- passing ownership of uniquely-owned objects with dynamic lifetime into functions
- acquiring ownership of uniquely-owned objects with dynamic lifetime from functions
- as the element type in move-aware containers, such as std::vector, which hold pointers to dynamically-allocated objects (e.g. if polymorphic behavior is desired)
boost::shared_array (replaced by std::shared_ptr it support new  object)- This is a
boost::shared_ptr for arrays. Basically
operator, and of course
delete  are baked in. This can be used in STL containers and as far as I know does everything
boost:shared_ptr does although you can’t use
boost::weak_ptr with these. You could however alternatively use a
boost::shared_ptr<std::vector<>> for similar functionality and to regain the ability to use
boost::weak_ptr for references.
Now this is a nice little class. It’s actually by far the most important of the smart pointer classes in Qt for its ingeniuty: it provides implicit sharing, with thread-safe copy-on-write. It requires that your class have a member called ref, which offers a function called ref() for increasing the reference count, and another called deref() that decreases that reference count and returns false when it drops to zero. If you derive your class from QSharedData, you get exactly that. Moreover, the size of a QSharedDataPointer object is exactly the size of a pointer. That means you can replace normal pointers with it in your code without breaking Binary Compatibility.
This class is the basis of all Qt value-type, implicit-shared, thread-safe copy-on-write recent classes, like QNetworkProxy. The only reason why it isn’t used in the base classes like QByteArray, QString and QList is that those classes were developed before this class was made. There’s nothing technically stopping the retrofitting of those classes with QSharedDataPointer.
So QSharedDataPointer is a strong smart pointer class, sharing data.
It has all the features you may want in a modern pointer class: it is polymorphic, it supports static, const, and dynamic casts, it implements atomic reference-counting and thread-safe semantics, it supports custom deleters. But note that, when I say it implements thread-safe semantics, it’s only for the pointer itself: remember it shares the pointer, not the data.
It comes with a cost, though: to support polymorphism correctly, the size of QSharedPointer is actually twice the size of a normal pointer. This means you cannot maintain binary compatibility while replacing a normal pointer with it in public parts of your API. You can use it internally in your code, though.
CC-BY-NC 4.0 licensed free for non-commercial usage
Author: Qingfeng XIA
copyright (C) 2011-2020
please keep the original link in your reference.