Il s'agit d'une classe de pointeur à référence légère, ne partageant que la valeur du pointeur, pas les données. Il ne peut opérer que sur des QObject et sur ses enfants. Ajoutée dans Qt 4.0, cette reprise de QGuardedPtr de Qt 3 (et de http://doc.trolltech.com/2.3/qguardedptr.html, de Qt 2) souffre d'un support peu fonctionnel de la constance, montrant ainsi son grand âge.

Un seul but : dire si, oui ou non, le QObject a été détruit. À l'inverse des versions 2 et 3, Qt 4 autorise le QObject à vivre dans plusieurs threads simultanément. Ce qui signifie que QPointer possède un défaut très sérieux : il laisse connaître l'existence d'un objet… mais sans aucune garantie quant à la ligne suivante ! Par exemple, ce bout de code peut se trouver en situation délicate.

QPointer<QObject> o = getObject();

// […]
if (!o.isNull())
    o->setProperty(“objectName”, “Object”);

Même si isNull retourne faux, il n'est pas possible d'obtenir la moindre garantie quant à la non-destruction de l'objet avant la ligne suivante !

Par conséquent, il n'est possible d'utiliser cette classe que si vous pouvez certifier, par des méthodes externes, que l'objet existe encore. Par exemple, QWidget et ses enfants ne peuvent être créés, manipulés ou détruits que dans le thread de la GUI. Si votre code est exécuté dans le thread de la GUI, ou qu'il est dans un thread bloqué, alors QPointer est sécurisé.

Maintenant, une jolie petite classe. En fait, c'est la plus importante de toutes les classes de pointeurs intelligents. De loin. Grâce à son ingéniosité : elle fournit un partage implicite, avec un système de COW thread-safe. Elle requiert que votre classe possède un membre ref, offrant une fonction ref(), qui augmente le compte de références, et une autre, unref(), qui l'abaisse et renvoie faux dès qu'il est nul. Si vous dérivez votre classe de QSharedData, c'est très exactement ce que vous aurez. De plus, un QSharedDataPointer a la même taille qu'un pointeur ! Ce qui signifie que vous pouvez remplacer vos pointeurs par ce type de pointeurs intelligents sans casser la compatibilité binaire.

Cette classe est la base de toutes les classes récentes de Qt, avec des données implicitement partagées, thread-safe, COW, comme QNetworkProxy. Si elle n'est pas utilisée dans d'autres classes comme QString, QByteArray ou QList, c'est que ces classes ont été développées bien avant que celle-ci soit en projet. Rien n'empêcherait leur portage vers ce type de pointeur intelligent.

Donc, ce type de pointeur est à référence forte, en partageant les données.

Cette classe est très exactement semblable à QSharedDataPointer. À une différence près : un détachement n'est jamais causé implicitement. Avec QExplicitelySharedDataPointer, detach() doit être explicitement appelée. Ceci vous permet le développement de classes de données partagées explicitement, ce que Qt4 ne propose plus, contrairement au QMemArray de Qt3.

Cela vous permet, en sus, de mieux contrôler l'opération de détachement. En fait, si les classes outil de Qt devaient être réimplémentées avec des pointeurs intelligents, elles utiliseraient ce type de pointeur. Utiliser QExplicitelySharedDataPointer permet de retarder le détachement jusqu'à la dernière extrémité, pour s'assurer qu'aucun accès mémoire inutile n'arrive.

C'est une classe utilisée en interne au module QtXmlPatterns. Basiquement, c'est votre pointeur de base, standard, inintelligent. Ainsi, c'est une implémentation d'un pointeur à forte référence. Pourtant, il ne le partage pas.

Au début, la seule raison pour laquelle cette classe existe est que le module QtXmlPatterns utilise intensivement les exceptions en interne. Pour survivre aux exceptions lancées, en évitant les fuites de mémoire, un emballage de pointeur est indiqué.

Cette classe fut créée pour répondre à QtPatternist::AutoPtr. Lors du début de son écriture, elle devait être prête pour Qt 4.4, et remplacer la classe interne, alors perçue comme une mauvaise utilisation de QExplicitelySharedDataPointer : cette dernière n'était utilisée que pour partager des données. Elle l'était pour partager des pointeurs. Les objets partagés n'étaient pas copiables. En recherchant un peu plus avant, on peut découvrir que cette classe est utilisée de la même manière dans QtScript, Phonon et Solid. En fait, QtScript l'avait introduite en ce but dans Qt 4.3.

Le compagnon de QSharedPointer implémente un contrôle renforcé sur le pointeur, en étant un pointeur intelligent à référence légère, ne partageant que le pointeur. Il travaille en tandem avec QSharedPointer : des QWeakPointer ne peuvent être créés que depuis des QSharedPointer, les premiers laissent savoir quand les seconds sont détruits.

Ils peuvent devenir QSharedPointer très facilement, d'une manière thread-safe. Réécrivons le code précédent :

QWeakPointer<Data> weak(getSharedPointer());

// […]
QSharedPointer<Data> ptr = weak;
if (!ptr.isNull())
    ptr->doSomething();

Ici, le QWeakPointer deviendra un QSharedPointer ou pas, mais cette décision est thread-safe. Si l'opération réussit, on peut être sûr que l'objet pointé ne sera pas supprimé.

Une belle fonctionnalité a été ajoutée dans Qt 4.6 : sa capacité à traquer les QObject, sans passer par un QSharedPointer. Cela peut être utilisé pour déterminer si un QObject a déjà été supprimé ou pas. Ainsi, il implémente un pointeur à référence légère. Cela vous semble familier ? C'est normal : on peut remplacer les vieillissants QPointer par d'autres pointeurs, plus récents, plus modernes, plus rapides, mais de taille différente.

C'est une autre classe interne, ajoutée pour remplacer le lent QPointer. Mais elle est en état de flux : on ne sait pas encore si on va la garder, ni même si on va l'utiliser. De toute façon, elle est interne, cela ne vous préoccupe pas.

Voici le dernier né de la série : il implémente un emballage non partagé de pointeur à forte référence. Il a été créé pour les besoins particuliers du portage sur la plateforme Symbian et de ses exceptions : nous avions besoin de libérer les ressources sans mettre de bloc catch / try partout. Un pointeur à portée résout ce genre de problèmes d'une manière très RAII. En fait, QScopedPointer est un parfait remplaçant pour QtPatternist::AutoPtr. Ils implémentent les mêmes fonctionnalités, la version interne peut être supprimée.

Certains pensent que nous aurions pu utiliser QSharedPointer. En fait, non. Ce candidat prend, en mémoire, la place de deux pointeurs. Pour pouvoir garder la compatibilité binaire, il ne peut en prendre qu'un seul. C'est aussi la raison pour laquelle QScopedPointer a un destructeur personnalisé en tant que paramètre template, à l'opposé d'un paramètre au constructeur : il n'a pas les 4 ou 8 bytes de place pour stocker le destructeur personnalisé.

De plus, QScopedPointer implémente un comptage de références atomique. Ce n'est pas très important qu'il soit atomique : le comptage de références n'est pas très utile dans les cas gérés par QScopedPointer.