Internal doc: explain how QSharedPointer works

1 files changed, 266 insertions, 0 deletions

diff --git a/src/corelib/tools/qsharedpointer.cpp b/src/corelib/tools/qsharedpointer.cpp
index e3e1db6..60c7db4 100644
--- a/src/corelib/tools/qsharedpointer.cpp
+++ b/src/corelib/tools/qsharedpointer.cpp
@@ -107,6 +107,249 @@
     cases, since they have the same functionality. See
     \l{QWeakPointer#tracking-qobject} for more information.
 
+    \section1 Optional pointer tracking
+
+    A feature of QSharedPointer that can be enabled at compile-time for
+    debugging purposes is a pointer tracking mechanism. When enabled,
+    QSharedPointer registers in a global set all the pointers that it tracks.
+    This allows one to catch mistakes like assigning the same pointer to two
+    QSharedPointer objects.
+
+    This function is enabled by defining the \tt{QT_SHAREDPOINTER_TRACK_POINTERS}
+    macro before including the QSharedPointer header.
+
+    It is safe to use this feature even with code compiled without the
+    feature. QSharedPointer will ensure that the pointer is removed from the
+    tracker even from code compiled without pointer tracking.
+
+    Note, however, that the pointer tracking feature has limitations on
+    multiple- or virtual-inheritance (that is, in cases where two different
+    pointer addresses can refer to the same object). In that case, if a
+    pointer is cast to a different type and its value changes,
+    QSharedPointer's pointer tracking mechanism mail fail to detect that the
+    object being tracked is the same.
+
+    \omit
+    \secton1 QSharedPointer internals
+
+    QSharedPointer is in reality implemented by two ancestor classes:
+    QtSharedPointer::Basic and QtSharedPointer::ExternalRefCount. The reason
+    for having that split is now mostly legacy: in the beginning,
+    QSharedPointer was meant to support both internal reference counting and
+    external reference counting.
+
+    QtSharedPointer::Basic implements the basic functionality that is shared
+    between internal- and external-reference counting. That is, it's mostly
+    the accessor functions into QSharedPointer. Those are all inherited by
+    QSharedPointer, which adds another level of shared functionality (the
+    constructors and assignment operators). The Basic class has one member
+    variable, which is the actual pointer being tracked.
+
+    QtSharedPointer::ExternalRefCount implements the actual reference
+    counting and introduces the d-pointer for QSharedPointer. That d-pointer
+    itself is shared with with other QSharedPointer objects as well as
+    QWeakPointer.
+
+    The reason for keeping the pointer value itself outside the d-pointer is
+    because of multiple inheritance needs. If you have two QSharedPointer
+    objects of different pointer types, but pointing to the same object in
+    memory, it could happen that the pointer values are different. The \tt
+    differentPointers autotest exemplifies this problem. The same thing could
+    happen in the case of virtual inheritance: a pointer of class matching
+    the virtual base has different address compared to the pointer of the
+    complete object. See the \tt virtualBaseDifferentPointers autotest for
+    this problem.
+
+    The d pointer is of type QtSharedPointer::ExternalRefCountData for simple
+    QSharedPointer objects, but could be of a derived type in some cases. It
+    is basically a reference-counted reference-counter.
+
+    \section2 d-pointer
+    \section3 QtSharedPointer::ExternalRefCountData
+
+    This class is basically a reference-counted reference-counter. It has two
+    members: \tt strongref and \tt weakref. The strong reference counter is
+    controlling the lifetime of the object tracked by QSharedPointer. a
+    positive value indicates that the object is alive. It's also the number
+    of QSharedObject instances that are attached to this Data.
+
+    When the strong reference count decreases to zero, the object is deleted
+    (see below for information on custom deleters). The strong reference
+    count can also exceptionally be -1, indicating that there are no
+    QSharedPointers attached to an object, which is tracked too. The only
+    case where this is possible is that of
+    \l{QWeakPointer#tracking-qobject}{QWeakPointers tracking a QObject}.
+
+    The weak reference count controls the lifetime of the d-pointer itself.
+    It can be thought of as an internal/intrusive reference count for
+    ExternalRefCountData itself. This count is equal to the number of
+    QSharedPointers and QWeakPointers that are tracking this object. (In case
+    the object tracked derives from QObject, this number is increased by 1,
+    since QObjectPrivate tracks it too).
+
+    ExternalRefCountData is a virtual class: it has a virtual destructor and
+    a virtual destroy() function. The destroy() function is supposed to
+    delete the object being tracked and return true if it does so. Otherwise,
+    it returns false to indicate that the caller must simply call delete.
+    This allows the normal use-case of QSharedPointer without custom deleters
+    to use only one 12- or 16-byte (depending on whether it's a 32- or 64-bit
+    architecture) external descriptor structure, without paying the price for
+    the custom deleter that it isn't using.
+
+    \section3 QtSharedPointer::ExternalRefCountDataWithDestroyFn
+
+    This class is not used directly, per se. It only exists to enable the two
+    classes that derive from it. It adds one member variable, which is a
+    pointer to a function (which returns void and takes an
+    ExternalRefCountData* as a parameter). It also overrides the destroy()
+    function: it calls that function pointer with \tt this as parameter, and
+    returns true.
+
+    That means when ExternalRefCountDataWithDestroyFn is used, the \tt
+    destroyer field must be set to a valid function that \b will delete the
+    object tracked.
+
+    This class also adds an operator delete function to ensure that simply
+    calls the global operator delete. That should be the behaviour in all
+    compilers already, but to be on the safe side, this class ensures that no
+    funny business happens.
+
+    On a 32-bit architecture, this class is 16 bytes in size, whereas it's 24
+    bytes on 64-bit. (On Itanium where function pointers contain the global
+    pointer, it can be 32 bytes).
+
+    \section3 QtSharedPointer::ExternalRefCountWithCustomDeleter
+
+    This class derives from ExternalRefCountDataWithDestroyFn and is a
+    template class. As template parameters, it has the type of the pointer
+    being tracked (\tt T) and a \tt Deleter, which is anything. It adds two
+    fields to its parent class, matching those template parameters: a member
+    of type \tt Deleter and a member of type \tt T*.
+
+    The purpose of this class is to store the pointer to be deleted and the
+    deleter code along with the d-pointer. This allows the last strong
+    reference to call any arbitrary function that disposes of the object. For
+    example, this allows calling QObject::deleteLater() on a given object.
+    The pointer to the object is kept here to avoid the extra cost of keeping
+    the deleter in the generic case.
+
+    This class is never instantiated directly: the constructors and
+    destructor are private. Only the create() function may be called to
+    return an object of this type. See below for construction details.
+
+    The size of this class depends on the size of \tt Deleter. If it's an
+    empty functor (i.e., no members), ABIs generally assign it the size of 1.
+    But given that it's followed by a pointer, up to 3 or 7 padding bytes may
+    be inserted: in that case, the size of this class is 16+4+4 = 24 bytes on
+    32-bit architectures, or 24+8+8 = 40 bytes on 64-bit architectures (48
+    bytes on Itanium with global pointers stored). If \tt Deleter is a
+    function pointer, the size should be the same as the empty structure
+    case, except for Itanium where it may be 56 bytes due to another global
+    pointer. If \tt Deleter is a pointer to a member function (PMF), the size
+    will be even bigger and will depend on the ABI. For architectures using
+    the Itanium C++ ABI, a PMF is twice the size of a normal pointer, or 24
+    bytes on Itanium itself. In that case, the size of this structure will be
+    16+8+4 = 28 bytes on 32-bit architectures, 24+16+8 = 48 bytes on 64-bit,
+    and 32+24+8 = 64 bytes on Itanium.
+
+    (Values for Itanium consider an LP64 architecture; for ILP32, pointers
+    are 32-bit in length, function pointers are 64-bit and PMF are 96-bit, so
+    the sizes are slightly less)
+
+    \section3 QtSharedPointer::ExternalRefCountWithContiguousData
+
+    This class also derives from ExternalRefCountDataWithDestroyFn and it is
+    also a template class. The template parameter is the type \tt T of the
+    class which QSharedPointer tracks. It adds only one member to its parent,
+    which is of type \tt T (the actual type, not a pointer to it).
+
+    The purpose of this class is to lay the \tt T object out next to the
+    reference counts, saving one memory allocation per shared pointer. This
+    is particularly interesting for small \tt T or for the cases when there
+    are few if any QWeakPointer tracking the object. This class exists to
+    implement the QSharedPointer::create() call.
+
+    Like ExternalRefCountWithCustomDeleter, this class is never instantiated
+    directly. This class also provides a create() member that returns the
+    pointer, and hides its constructors and destructor. (With C++0x, we'd
+    delete them).
+
+    The size of this class depends on the size of \tt T.
+
+    \section3 Instantiating ExternalRefCountWithCustomDeleter and ExternalRefCountWithContiguousData
+
+    Like explained above, these classes have private constructors. Moreover,
+    they are not defined anywhere, so trying to call \tt{new ClassType} would
+    result in a compilation or linker error. Instead, these classes must be
+    constructed via their create() methods.
+
+    Instead of instantiating the class by the normal way, the create() method
+    calls \tt{operator new} directly with the size of the class, then calls
+    the parent class's constructor only (ExternalRefCountDataWithDestroyFn).
+    This ensures that the inherited members are initialised properly, as well
+    as the virtual table pointer, which must point to
+    ExternalRefCountDataWithDestroyFn's virtual table. That way, we also
+    ensure that the virtual destructor being called is
+    ExternalRefCountDataWithDestroyFn's.
+
+    After initialising the base class, the
+    ExternalRefCountWithCustomDeleter::create() function initialises the new
+    members directly, by using the placement \tt{operator new}. In the case
+    of the ExternalRefCountWithContiguousData::create() function, the address
+    to the still-uninitialised \tt T member is saved for the callee to use.
+    The member is only initialised in QSharedPointer::create(), so that we
+    avoid having many variants of the internal functions according to the
+    arguments in use for calling the constructor.
+
+    When initialising the parent class, the create() functions pass the
+    address of the static deleter() member function. That is, when the
+    virtual destroy() is called by QSharedPointer, the deleter() functions
+    are called instead. These functiosn static_cast the ExternalRefCountData*
+    parameter to their own type and execute their deletion: for the
+    ExternalRefCountWithCustomDeleter::deleter() case, it runs the user's
+    custom deleter, then destroys the deleter; for
+    ExternalRefCountWithContiguousData::deleter, it simply calls the \tt T
+    destructor directly.
+
+    By not calling the constructor of the derived classes, we avoid
+    instantiating their virtual tables. Since these classes are
+    template-based, there would be one virtual table per \tt T and \tt
+    Deleter type. (This is what Qt 4.5 did)
+
+    Instead, only one non-inline function is required per template, which is
+    the deleter() static member. All the other functions can be inlined.
+    What's more, the address of deleter() is calculated only in code, which
+    can be resolved at link-time if the linker can determine that the
+    function lies in the current application or library module (since these
+    classes are not exported, that is the case for Windows or for builds with
+    \tt{-fvisibility=hidden}).
+
+    In contrast, a virtual table would require at least 3 relocations to be
+    resolved at module load-time, per module where these classes are used.
+    (In the Itanium C++ ABI, there would be more relocations, due to the
+    RTTI)
+
+    \section3 Modifications due to pointer-tracking
+
+    To ensure that pointers created with pointer-tracking enabled get
+    un-tracked when destroyed, even if destroyed by code compiled without the
+    feature, QSharedPointer modifies slightly the instructions of the
+    previous sections.
+
+    When ExternalRefCountWithCustomDeleter or
+    ExternalRefCountWithContiguousData are used, their create() functions
+    will set the ExternalRefCountDataWithDestroyFn::destroyer function
+    pointer to safetyCheckDeleter() instead. These static member functions
+    simply call internalSafetyCheckRemove2() before passing control to the
+    normal deleter() function.
+
+    If neither custom deleter nor QSharedPointer::create() are used, then
+    QSharedPointer uses a custom deleter of its own: the normalDeleter()
+    function, which simply calls \tt delete. By using a custom deleter, the
+    safetyCheckDeleter() procedure described above kicks in.
+
+    \endomit
+
     \sa QSharedDataPointer, QWeakPointer
 */
 
@@ -182,6 +425,29 @@
     QWeakPointers created from QObject should never be passed to code that
     hasn't been recompiled.
 
+    \omit
+    \secton1 QWeakPointer internals
+
+    QWeakPointer shares most of its internal functionality with
+    \l{QSharedPointer#qsharedpointer-internals}{QSharedPointer}, so see that
+    class's internal documentation for more information.
+
+    QWeakPointer requires an external reference counter in order to operate.
+    Therefore, it is incompatible by design with \l QSharedData-derived
+    classes.
+
+    It has a special QObject constructor, which works by calling
+    QtSharedPointer::ExternalRefCountData::getAndRef, which retrieves the
+    d-pointer from QObjectPrivate. If one isn't set yet, that function
+    creates the d-pointer and atomically sets it.
+
+    If getAndRef needs to create a d-pointer, it sets the strongref to -1,
+    indicating that the QObject is not shared: QWeakPointer is used only to
+    determine whether the QObject has been deleted. In that case, it cannot
+    be upgraded to QSharedPointer (see the previous section).
+
+    \endomit
+
     \sa QSharedPointer
 */