/****************************************************************************

**

** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).

** All rights reserved.

** Contact: Nokia Corporation (qt-info@nokia.com)

**

** This file is part of the QtCore module of the Qt Toolkit.

**

** $QT_BEGIN_LICENSE:LGPL$

** No Commercial Usage

** This file contains pre-release code and may not be distributed.

** You may use this file in accordance with the terms and conditions

** contained in the Technology Preview License Agreement accompanying

** this package.

**

** GNU Lesser General Public License Usage

** Alternatively, this file may be used under the terms of the GNU Lesser

** General Public License version 2.1 as published by the Free Software

** Foundation and appearing in the file LICENSE.LGPL included in the

** packaging of this file.  Please review the following information to

** ensure the GNU Lesser General Public License version 2.1 requirements

** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.

**

** In addition, as a special exception, Nokia gives you certain additional

** rights.  These rights are described in the Nokia Qt LGPL Exception

** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.

**

** If you have questions regarding the use of this file, please contact

** Nokia at qt-info@nokia.com.

**

**

**

**

**

**

**

**

** $QT_END_LICENSE$

**

****************************************************************************/

#include "qsharedpointer.h"

// to be sure we aren't causing a namespace clash:

#include "qshareddata.h"

/*!

    \class QSharedPointer

    \brief The QSharedPointer class holds a strong reference to a shared pointer

    \since 4.5

    \reentrant

    The QSharedPointer is an automatic, shared pointer in C++. It

    behaves exactly like a normal pointer for normal purposes,

    including respect for constness.

    QSharedPointer will delete the pointer it is holding when it goes

    out of scope, provided no other QSharedPointer objects are

    referencing it.

    A QSharedPointer object can be created from a normal pointer,

    another QSharedPointer object or by promoting a

    QWeakPointer object to a strong reference.

    \section1 Thread-Safety

    QSharedPointer and QWeakPointer are thread-safe and operate

    atomically on the pointer value. Different threads can also access

    the same QSharedPointer or QWeakPointer object at the same time

    without need for locking mechanisms.

    It should be noted that, while the pointer value can be accessed

    in this manner, QSharedPointer and QWeakPointer provide no

    guarantee about the object being pointed to. Thread-safety and

    reentrancy rules for that object still apply.

    \section1 Other Pointer Classes

    Qt also provides two other pointer wrapper classes: QPointer and

    QSharedDataPointer. They are incompatible with one another, since

    each has its very different use case.

    QSharedPointer holds a shared pointer by means of an external

    reference count (i.e., a reference counter placed outside the

    object). Like its name indicates, the pointer value is shared

    among all instances of QSharedPointer and QWeakPointer. The

    contents of the object pointed to by the pointer should not

    considered shared, however: there is only one object. For that

    reason, QSharedPointer does not provide a way to detach or make

    copies of the pointed object.

    QSharedDataPointer, on the other hand, holds a pointer to shared

    data (i.e., a class derived from QSharedData). It does so by means

    of an internal reference count, placed in the QSharedData base

    class. This class can, therefore, detach based on the type of

    access made to the data being guarded: if it's a non-const access,

    it creates a copy atomically for the operation to complete.

    QExplicitlySharedDataPointer is a variant of QSharedDataPointer, except

    that it only detaches if QExplicitlySharedDataPointer::detach() is

    explicitly called (hence the name).

    QScopedPointer simply holds a pointer to a heap allocated object and

    deletes it in its destructor. This class is useful when an object needs to

    be heap allocated and deleted, but no more. QScopedPointer is lightweight,

    it makes no use of additional structure or reference counting.

    Finally, QPointer holds a pointer to a QObject-derived object, but it

    does so weakly. QPointer can be replaced by QWeakPointer in almost all

    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, QScopedPointer

*/

/*!

    \class QWeakPointer

    \brief The QWeakPointer class holds a weak reference to a shared pointer

    \since 4.5

    \reentrant

    The QWeakPointer is an automatic weak reference to a

    pointer in C++. It cannot be used to dereference the pointer

    directly, but it can be used to verify if the pointer has been

    deleted or not in another context.

    QWeakPointer objects can only be created by assignment from a

    QSharedPointer. The exception is pointers derived from QObject: in that

    case, QWeakPointer serves as a replacement to QPointer.

    It's important to note that QWeakPointer provides no automatic casting

    operators to prevent mistakes from happening. Even though QWeakPointer

    tracks a pointer, it should not be considered a pointer itself, since it

    doesn't guarantee that the pointed object remains valid.

    Therefore, to access the pointer that QWeakPointer is tracking, you must

    first promote it to QSharedPointer and verify if the resulting object is

    null or not. QSharedPointer guarantees that the object isn't deleted, so

    if you obtain a non-null object, you may use the pointer. See

    QWeakPointer::toStrongRef() for more an example.

    QWeakPointer also provides the QWeakPointer::data() method that returns

    the tracked pointer without ensuring that it remains valid. This function

    is provided if you can guarantee by external means that the object will

    not get deleted (or if you only need the pointer value) and the cost of

    creating a QSharedPointer using toStrongRef() is too high.

    That function can also be used to obtain the tracked pointer for

    QWeakPointers that cannot be promoted to QSharedPointer, such as those

    created directly from a QObject pointer (not via QSharedPointer).

    \section1 Tracking QObject

    QWeakPointer can be used to track deletion classes derives from QObject,

    even if they are not managed by QSharedPointer. When used in that role,

    QWeakPointer replaces the older QPointer in all use-cases. QWeakPointer

    is also more efficient than QPointer, so it should be preferred in all

    new code.

    To do that, QWeakPointer provides a special constructor that is only

    available if the template parameter \tt T is either QObject or a class

    deriving from it. Trying to use that constructor if \tt T does not derive

    from QObject will result in compilation errors.

    To obtain the QObject being tracked by QWeakPointer, you must use the

    QWeakPointer::data() function, but only if you can guarantee that the

    object cannot get deleted by another context. It should be noted that

    QPointer had the same constraint, so use of QWeakPointer forces you to

    consider whether the pointer is still valid.

    QObject-derived classes can only be deleted in the thread they have

    affinity to (which is the thread they were created in or moved to, using

    QObject::moveToThread()). In special, QWidget-derived classes cannot be

    created in non-GUI threads nor moved there. Therefore, guaranteeing that

    the tracked QObject has affinity to the current thread is enough to also

    guarantee that it won't be deleted asynchronously.

    Note that QWeakPointer's size and data layout do not match QPointer, so

    it cannot replace that class in a binary-compatible manner.

    Care must also be taken with QWeakPointers created directly from QObject

    pointers when dealing with code that was compiled with Qt versions prior

    to 4.6. Those versions may not track the reference counters correctly, so

    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, QScopedPointer

*/

/*!

    \fn QSharedPointer::QSharedPointer()

    Creates a QSharedPointer that points to null (0).

*/

/*!

    \fn QSharedPointer::~QSharedPointer()

    Destroys this QSharedPointer object. If it is the last reference to

    the pointer stored, this will delete the pointer as well.

*/

/*!

    \fn QSharedPointer::QSharedPointer(T *ptr)

    Creates a QSharedPointer that points to \a ptr. The pointer \a ptr

    becomes managed by this QSharedPointer and must not be passed to

    another QSharedPointer object or deleted outside this object.

*/

/*!

    \fn QSharedPointer::QSharedPointer(T *ptr, Deleter deleter)

    Creates a QSharedPointer that points to \a ptr. The pointer \a ptr

    becomes managed by this QSharedPointer and must not be passed to

    another QSharedPointer object or deleted outside this object.

    The \a deleter paramter specifies the custom deleter for this

    object. The custom deleter is called when the strong reference

    count drops to 0 instead of the operator delete(). This is useful,

    for instance, for calling deleteLater() in a QObject instead:

    \code

    static void doDeleteLater(MyObject *obj)

    {

        obj->deleteLater();

    }

    void otherFunction()

    {

        QSharedPointer<MyObject> obj =

            QSharedPointer<MyObject>(new MyObject, doDeleteLater);

        // continue using obj

        obj.clear();    // calls obj->deleteLater();

    }

    \endcode

    It is also possible to specify a member function directly, as in:

    \code

        QSharedPointer<MyObject> obj =

            QSharedPointer<MyObject>(new MyObject, &QObject::deleteLater);

    \endcode

    \sa clear()

*/

/*!

    \fn QSharedPointer::QSharedPointer(const QSharedPointer<T> &other)

    Creates a QSharedPointer object that shares \a other's pointer.

    If \tt T is a derived type of the template parameter of this class,

    QSharedPointer will perform an automatic cast. Otherwise, you will

    get a compiler error.

*/

/*!

    \fn QSharedPointer::QSharedPointer(const QWeakPointer<T> &other)

    Creates a QSharedPointer by promoting the weak reference \a other