Pointeurs intelligents

À partir du moment où on alloue dynamiquement de la mémoire, il faut la désallouer quand on a fini de s'en servir. Sinon, la mémoire reste réservée, et au fur et à mesure que le temps passe, notre programme va « manger » la mémoire disponible sur la machine, conduisant à des baisses de performance et à des explosions, c'est ce qu'on nomme une fuite mémoire.

Cette contrainte pose deux problèmes : Elle oblige déjà à une grande discipline de codage, afin de ne pas oublier un delete quelque part, et en plus, elle est très difficile à mettre en œuvre correctement.

int g();

int f()
{
    int *i = new int(42);
    g();
    delete i;
}

class A
{
public:
    À() : i(new int(314)), j(new int(42)) {}
    ~À()
    {
        delete j;
        delete i;
    }
private:
    // Fonctions déclarées privées pour empêcher le compilateur de générer 
    // un constructeur de recopie et un opérateur d'affectation par défaut.
    A(À const &);  
    À& operator= (A const &);

    int *i;
    int *j;
};

Dans ces deux cas, on peut penser avoir correctement fait le travail de désallocation. Mais ce n'est pas le cas. Si par exemple la fonction g lance une exception, le delete i ne sera jamais appelé.

Dans le second cas, même problème, si le new int(42) échoue, par manque de mémoire, une exception est lancée. Cette exception fait que la classe A sera considérée comme n'ayant jamais été construite, et on ne passera donc pas dans son destructeur. La mémoire allouée pour i ne sera donc jamais libérée.

Le plus difficile, c'est que tant qu'une exception n'est pas lancée à un moment bien précis, le code va tourner sans problèmes. Et même si l'exception est lancée, une fuite mémoire n'est pas forcément très visible et peut donc passer inaperçue pendant longtemps. Ce genre d'erreur risque donc fortement de ne pas être détectée pendant la phase de tests, jusqu'au jour où elle deviendra très gênante, quand le code sera déployé…

La solution classique à ce problème en C++ est le RAII. Dans les deux exemples cités, le RAII classique résoudrait le problème. Par contre, le RAII lie la durée de vie des objets avec la portée de la variable locale. C'est souvent un peu simpliste, puisque justement, si on a utilisé de l'allocation dynamique, c'est que l'on souhaite décorréler la durée de vie de l'objet avec la portée où il est déclaré. Les pointeurs intelligents peuvent être vus comme une extension du RAII ayant une gestion plus fine de la durée de vie de l'objet pointée. Parmi ceux-ci, boost::scoped_ptr représente ni plus ni moins que la mise en place de RAII pour gérer de la mémoire.

Le code suivant possède des erreurs :

int *i = new int(14);
delete i;
delete i; // Erreur : Pas deux désallocations
int *j;
delete j; // Erreur : Désallocation d'une zone non allouée
int *k = NULL;
delete k; // Ok : On peut faire delete NULL sans problèmes

La règle est qu'on ne peut désallouer qu'une zone qui est allouée (ou NULL). Ce cas se présente moins souvent que le cas précédent.

Le dernier type de problème pouvant arriver, c'est de tenter de déréférencer un pointeur invalide. Ça arrive le plus souvent quand plusieurs pointeurs pointent sur une même zone de mémoire, que l'on fait delete sur l'un des pointeurs, mais que les autres pointeurs ne sont pas au courant et continuent de tenter d'y accéder.

int *i = new int(42);
int *j = i;
delete i;
*j = 2;

Prenons par exemple une fonction :

MaStructure const *getInformation();

Il est évident que cette fonction va retourner un pointeur sur une zone de mémoire contenant les informations que l'on désire. Mais qu'est-on censé faire de ce pointeur quand on a fini d'utiliser ces informations ? Rien ? L'effacer avec delete ? L'effacer avec free ? Autre chose ? On n'en sait rien a priori, toutes ces possibilités ayant des cas d'application concrets. Certes, la documentation associée à la fonction getInformation, si elle est écrite correctement, doit nous fournir la réponse, mais il serait plus agréable de ne pas avoir à se reposer sur une documentation pour ce genre de choses.

On veut manipuler des formes mathématiques, des cercles, des rectangles… Dans le monde idéal, on écrirait du code comme ça :

vector<Shape> v;
v.push_back(Rectangle(0, 0, 10, 20));
v.push_back(Circle(0, 0, 10));
for(vector<Shape>::iterator it = v.begin();
    it != v.end();
    ++it)
{
    it->draw();
}

vector<Shape> v2 = v;
for(vector<Shape>::iterator it = v2.begin();
    it != v2.end();
    ++it)
{
    it->move(2, 2);
}

Sauf que comme on le sait, ça ne marche pas ainsi. Il y a ce qu'on appelle du slicing. Si on essaye par exemple de mettre un Circle dans notre vecteur, on va se retrouver quelque part à l'intérieur du vecteur à faire un code équivalent à Shape s = aCircle. Or, un objet a en C++ un type bien déterminé, ici Shape, avec un arrangement mémoire connu à la compilation. On ne peut pas faire entrer un Circle dans de la mémoire prévue pour un Shape, il n'y a pas assez de place. Cette opération va donc convertir le Circle en Shape, ce qui correspond à supprimer toutes les variables membres ajoutées au niveau de la classe dérivée, à couper (slice) l'objet pour n'en garder que la partie définie dans la classe de base.

La façon d'utiliser du polymorphisme en C++ passe par des pointeurs (ou des références). On a une zone mémoire allouée pour un Circle, mais on va y accéder par l'intermédiaire d'un pointeur sur un Shape, et c'est ce pointeur que l'on va mettre dans notre conteneur :

vector<Shape*> v;
v.push_back(new Rectangle(0, 0, 10, 20));
v.push_back(new Circle(0, 0, 10));
for(vector<Shape*>::iterator it = v.begin();
    it != v.end();
    ++it)
{
    (*it)->draw();
}

vector<Shape*> v2 = v;
for(vector<Shape*>::iterator it = v2.begin();
    it != v2.end();
    ++it)
{
    (*it)->move(2, 2);
}

Les problèmes sont multiples : On doit désormais s'occuper de désallouer correctement ce qui a été alloué (ce que je n'ai pas fait ici), de plus, on a sans forcément le vouloir une sémantique d'entité, alors qu'initialement on avait une sémantique de valeur. Ainsi, la deuxième partie du code modifie aussi le contenu de v, ce qui n'était pas le cas dans la version précédente.

Nous sommes dans le cas où l'on utilise des pointeurs alors que l'on souhaite manipuler des données ayant une sémantique de valeur, uniquement parce que l'on veut du polymorphisme. L'idiome classique pour gérer ce genre de cas est l'idiome lettre enveloppe. On va ici voir une autre approche, un peu plus générique dans sa mise en œuvre : On va demander à l'utilisateur de nos classes de manipuler des pointeurs intelligents vers les objets, mais ces pointeurs auront la particularité de copier les objets pointés lorsqu'on copie le pointeur, permettant de restaurer une sémantique de valeur.

Le premier point, c'est de choisir comment nommer notre classe. On l'appellera ValuePtr, pour indiquer qu'il s'agit d'un pointeur avec une sémantique de valeur.

On veut pouvoir créer des ValuePtr qui pointent sur divers types de données, des Shape, des Circle, des Rectangle, mais aussi d'autres types que l'on n'a pas encore envisagés. On va donc faire de ValuePtr un template, qui aura comme argument le type sur lequel le pointeur intelligent va pointer.

Enfin, notre classe va encapsuler un pointeur, et aura donc une donnée membre de ce type. Voici donc la structure de base de notre pointeur intelligent.

template<class T>
class ValuePtr
{
private:
    T* myPtr;
};

On veut que notre pointeur intelligent ressemble en termes d'utilisation à un pointeur. Les deux opérations les plus fondamentales que l'on peut effectuer sur un pointeur p, c'est accéder à l'objet pointé, par l'écriture *p, ou accéder au contenu de l'objet pointé, par l'écriture p->.

L'écriture *p n'est en pratique pas utilisée si souvent que ça, mais il n'est pas compliqué de la fournir. On va définir l'opérateur * unaire pour qu'il effectue cette tâche. Comme on veut qu'à partir de cet opérateur, l'utilisateur accède directement à l'objet pointé et non à une copie, cet opérateur va retourner une référence vers le contenu du pointeur.

template<class T>
class ValuePtr
{
public:
    T& operator*() const {return *myPtr;}
private:
    T* myPtr;
};

De son côté, l'écriture p-> est à la base de l'utilisation du pointeur. On va cette fois la reproduire en surchargeant l'opérateur -> sur notre classe :

template<class T>
class ValuePtr
{
public:
    T* operator->() const {return myPtr;}
private:
    T* myPtr;
};

L'opérateur -> est un peu spécial. Alors qu'en général, a @ b se traduit par operator@(a, b) ou a.operator@(b), dans le cas de l'opérateur ->, a->b se traduit par (a.operator->())->b. Donc, notre opérateur -> retourne le pointeur nu interne, et le programme va transmettre au pointeur nu ce que l'utilisateur a voulu faire à notre ValuePtr. Contrairement au cas précédent, le pointeur nu n'est utilisé que comme une valeur temporaire, auquel l'utilisateur n'a pas un accès direct, et il ne peut donc pas faire de bêtises avec.

Nous voulons que quand on crée un ValuePtr, il prenne la responsabilité d'un pointeur que l'on passe en argument du constructeur. Ainsi, quand on détruit le ValuePtr, il va automatiquement détruire la donnée pointée par ptr.

template<class T>
class ValuePtr
{
public:
    ValuePtr(T* ptr) : myPtr(ptr) {}
    ~ValuePtr() {delete myPtr;}
    T* operator->() {return myPtr;}
private:
    T* myPtr;
};

Que doit-il se passer quand l'utilisateur copie le pointeur ? On veut tout simplement que la valeur pointée soit copiée elle aussi. Une première tentative pourrait être de passer par le constructeur de copie de la valeur pointée :

template<class T>
class ValuePtr
{
public:
    ValuePtr(ValuePtr const &other) : 
        myPtr(new T (*(other.myPtr))
    {}
    ValuePtr &operator=(ValuePtr const &other)
    {
        // Je sais que ce code ne gère pas l'autoaffectation
        //, mais le but est juste de présenter le concept
        delete myPtr;
        myPtr = new T(*(other.myPtr));
        return *this;
    }
    // ...
};

Le problème est que notre principal cas d'utilisation est pour des classes faisant partie d'une hiérarchie polymorphe. On peut donc avoir un ValuePtr<Shape> qui en fait pointe sur un Circle, mais dans la copie, on va créer un nouvel objet du type Shape. Il nous faut utiliser l'idiome du constructeur de copie virtuel : Nous allons imposer à notre type T d'avoir une fonction (virtuelle en général) clone qui produit un double de l'objet existant. On va tant qu'à faire en profiter pour corriger les problèmes d'autoaffectation et d'exception safety de l'opérateur d'affectation.

template<class T>
class ValuePtr
{
public:
    ValuePtr(ValuePtr const &other) : 
        myPtr(other->clone()))
    {}
    void swap(ValuePtr &other)
    {
        std::swap(myPtr, other.myPtr);
    }
    ValuePtr &operator=(ValuePtr const &other)
    {
        ValuePtr<T> temp(other);
        swap(temp);
    }
    // ...
};

Nous avons désormais un ValuePtr fonctionnel, mais très minimaliste. Voyons comment on peut en rendre l'usage plus simple pour l'utilisateur.

Actuellement, on impose au type pointé d'implémenter l'idiome du constructeur virtuel par une fonction nommée clone(). Pas Clone(), ni Copy(), ni copie(), ni… C'est très restrictif. Trop.

La solution future, quand le C++0x sera sorti, sera simplement de définir dans le concept associé à notre template que l'on a besoin de faire p.clone() sur le paramètre template, et de laisser l'utilisateur utiliser les concept_map pour faire correspondre sa fonction de copie avec ce que veut le concept. Voyons étape par étape comment y parvenir.

On déclare dans un concept qu'un objet Clonable est un objet qui possède une fonction clone retournant un pointeur du même type. Ce concept est auto afin que toutes les classes ayant cette fonction soient immédiatement considérées comme répondant au concept (sinon, il faudrait définir un concept map dans tous les cas).

auto concept Clonable<class T>
{
    T* T::clone();
}

Ensuite, on utilise ce concept pour définir notre pointeur intelligent. Ça a deux effets :

• tout d'abord, si jamais dans l'implémentation de notre pointeur intelligent, on essaye d'utiliser sur un objet de type T une fonctionnalité autre que celle définie dans Clonable, le code échouera ;
• ensuite, si on essaye d'instancier un pointeur intelligent sur un type non Clonable, l'instanciation échouera (avec un message d'erreur qui devrait avoir du sens pour l'utilisateur).

template <Clonable T>
class ValuePtr
{
public:
    ValuePtr(ValuePtr const &other) : myPtr(other->clone())
    {
    }
    // ...
};

Pour l'instant on n'a rien résolu, notre classe A par exemple n'étant a priori pas Clonable :

class A
{
public:
    A* copy() {return new A(*this);}
};

Mais finalement, la personne désirant créer un ValuePtr<A> peut dire que si, A est en fait Clonable, et que quand le pointeur intelligent désire appeler la fonctionnalité clone promise dans le concept, il peut en fait appeler la fonction copy sur l'objet en cours. Il suffit pour ça d'écrire une concept_map :

concept_map Clonable<A>
{
    A* À::clone() {this->copy();}
};

Et voilà, le tour est joué.

La solution dans les frontières du langage actuel consiste à passer par l'intermédiaire de ce qu'on appelle une classe de traits. Comme d'habitude, on résout le problème en ajoutant une indirection supplémentaire :

template<class T>
class CloneTraits
{
    T* clone(T* t) {return t->clone();}
}

template<class T>
class ValuePtr
{
public:
    ValuePtr(ValuePtr const &other) : 
        myPtr(CloneTraits::clone(other.myPtr))
    {}
    // ...
};

A priori, on n'a pas gagné grand-chose, juste la complexité apportée par une classe supplémentaire. Par contre, la personne qui souhaite utiliser notre pointeur intelligent avec un type ayant une autre écriture pour clone peut toujours spécialiser la classe CloneTraits :

class A
{
public:
    À* copy();
};

template<>
class CloneTraits<A>
{
    A* clone(A* a) {return a->copy();}
};

Si vous voulez plus de détails à propos du fonctionnement de cette technique, vous pouvez aller voir Présentation des classes de Traits et de Politiques en C++ par Alp Mestan

Il y a bien des opérations que l'on peut faire sur un pointeur qui ne sont pas prises en compte par notre type. Par exemple, on peut convertir un pointeur sur une classe dérivée vers un pointeur sur une classe de base, ou plus généralement, si U est convertible en T, U* est convertible en T* :

template<class T>
class ValuePtr
{
public:
    template<class U> ValuePtr(ValuePtr<U> const &uPtr) :
        myPtr(uPtr.get()->clone())
    {}
    T* get() {return myPtr;}
    // ...
};

Deux remarques : Déjà, la déclaration de ce constructeur ne dispense pas du constructeur de copie, même si on pourrait croire qu'il s'agit d'un cas plus général de ce dernier. En effet, un constructeur template n'est jamais pris en compte quand il s'agit de trouver un constructeur de copie. Ensuite, ValuePtr<U> étant un type distinct de ValuePtr<T>, on ne peut pas accéder à la donnée privée uPtr.myPtr, d'où la présence de la fonction get, qui peut de toute façon être utile en elle même.

Parmi les opérations supportées par les pointeurs, il y a les opérations arithmétiques, mais celles-ci servent à gérer des tableaux, et sont donc peu utiles pour notre cas.

Il y a aussi la gestion de pointeur nul (par exemple, un ValuePtr créé avec le constructeur par défaut), et le fait qu'un tel pointeur doive se convertir en false dans un contexte où un booléen est attendu. Le plus basique pour y parvenir est (le explicit devant operator bool n'est possible qu'en C++0x. Pour obtenir du code valide en C++98, il faut simplement ne pas le mettre ; on s'expose alors à quelques inconvénients, lire safe bool pour plus d'informations) :

template<class T>
class ValuePtr
{
public:
    explicit operator bool() const
    {
         return myPtr;
    }
};

Enfin, on pourrait vouloir permettre la conversion depuis notre pointeur intelligent vers un pointeur nu. La méthode pour le faire consisterait à surcharger operator T*(), mais ce n'est pas forcément une bonne idée. En effet, cette conversion implicite donnerait un accès direct au pointeur nu, et permettrait de fausses manipulations. Bien qu'un tel accès soit probablement nécessaire dans certains cas, il semble plus judicieux de ne le fournir que par une fonction, ce qui oblige un appel explicite, et permet de s'assurer qu'il s'agit bien d'un choix conscient de l'utilisateur.

On peut voir que si définir un pointeur intelligent n'est pas très compliqué en principe, en définir un bon commence à devenir plus difficile. Et encore, je suis passé à côté de plein d'aspects (multithreading, par exemple). D'où l'intérêt d'avoir à notre disposition des pointeurs mitonnés aux petits oignons au fil des ans par des experts du domaine.

Comme il est usuel, un shared_ptr est un template ayant comme paramètre le type d'élément sur lequel il doit pointer. Prenons un petit code d'exemple :

void f()
{
    shared_ptr<int> a(new int (42));
    cout << a.use_count() << endl;
    shared_ptr<int> b = a;
    cout << a.use_count() << endl;
    {
        shared_ptr<int> c;
        shared_ptr<int> d (new int (314));
        cout << a.use_count() << endl;
        c = a;
        cout << a.use_count() << endl;
        d = c;
        cout << a.use_count() << endl;
    }
    cout << a.use_count() << endl;
    b.reset();
    cout << a.use_count() << endl;
}

La fonction use_count affiche la valeur du comptage de référence d'un shared_ptr. Elle ne sert qu'à des fins de débogage, ou d'explication comme ici. Ce programme va commencer par afficher 1, c'est-à-dire qu'au début, il n'y a qu'un seul pointeur pointant sur l'objet (ici, un entier valant 42). On peut noter que c'est une bonne habitude de stocker dès que possible un pointeur nu dans un pointeur intelligent, afin de s'assurer qu'il n'aura pas l'occasion de fuir. À tel point que le standard défini une fonction make_shared qui évite toute présence d'un pointeur nu dans le code utilisateur, et que l'on aurait pu utiliser ainsi :

shared_ptr<int> a = make_shared<int>(42);

Cette fonction a aussi l'avantage d'être plus sûre (voir plus loin) et d'offrir un gain de performances par rapport au code précédent. Seul problème : Elle demande des techniques spécifiques à C++0x pour pouvoir être implémentée, et il faut donc apprendre encore quelque temps à s'en passer.

Revenons à notre premier exemple. La deuxième ligne affiche 2 : On a construit un autre shared_ptr qui pointe sur la même zone. La troisième ligne affiche toujours 2 : On a construit un pointeur c sur un entier, mais sans l'initialiser. Un tel pointeur ne pointe sur rien. C'est un peu l'équivalent d'un pointeur nul, pour des shared_ptr. De même, le pointeur d pointe sur un autre entier. Il n'y a donc aucune raison de modifier le comptage de référence vers notre entier 42.

Par contre, à la ligne suivante, ce comptage passe à 3 : On a fait pointer c vers le même objet, le comptage augmente donc. À la ligne suivante, le compteur est encore incrémenté, puisque d pointe désormais aussi sur notre objet. À cette occasion, d s'est arrêté de pointer sur l'entier valant 314, et le comptage de référence de cet objet a donc diminué. Comme il a atteint 0 (il n'y avait que d pour pointer dessus), cet objet a donc été détruit.

Quand on sort du scope, les variables c et d sont détruites, notre comptage de référence redescend donc à 2. Puis, on appelle b.reset(), qui a le même effet que si on avait écrit b = shared_ptr<int>(); b ne pointe plus sur rien après cet appel. La dernière ligne que l'on affiche est donc 1. À la fin de la fonction, a sera détruit, faisant passer le comptage de référence à 0, et l'entier valant 42 sera détruit.

Il existe un certain nombre de conversions possibles entre des pointeurs nus. Les conversions équivalentes existent entre les shared_ptrs. En voici quelques exemples :

class A {/*...*/};
class B : public A {/*...*/};

B* b1(new B);
A* a(b1);
B* b2 = dynamic_cast<B*>(a);

shared_ptr<B> sb1(new B);
shared_ptr<A> sa(sb1);
shared_ptr<B> sb2 = dynamic_pointer_cast<B>(sa);

On peut noter en particulier que le mot clef dynamic_cast est remplacé pour les shared_ptr par une fonction dynamic_pointer_cast qui s'utilise de manière semblable (sauf que le paramètre template est B, et non pas shared_ptr<B>), et qui retourne un pointeur ne pointant sur rien si la conversion n'a pu avoir lieu. Il existe de même une fonction static_pointer_cast et mimant l'effet d'un static_cast pour un pointeur nu.

Il y a deux cas où malgré l'utilisation de shared_ptrs, on a toujours des fuites mémoires. Le premier est lié non pas aux shared_ptrs, mais au fait que, temporairement, la mémoire n'a pas été gérée par des shared_ptrs. Soit le code suivant, a priori bien intentionné :

int f(shared_ptr<int> i, int j);
int g();

f(shared_ptr<int> (new int (42)), g());

Ce code respecte bien le conseil d'enrober au plus vite un pointeur nu dans un pointeur, mais il présente un risque de fuite mémoire. En effet, le compilateur doit effectuer 4 actions quand il voit cette ligne :

1. Créer un entier valant 42 dans une nouvelle zone mémoire allouée pour l'occasion par new ;
2. Créer un shared_ptr avec le pointeur obtenu à l'étape 1 ;
3. Appeler la fonction g ;
4. Appeler la fonction f.

Il y a quelques contraintes d'ordre entre ces opérations, par exemple 2 ne peut avoir lieu qu'après 1, et 4 qu'à la fin. Par contre rien n'empêche le compilateur de choisir l'ordre : 1 3 2 4.

Dans ce cas, si l'appel de g lance une exception, comme le shared_ptr n'a pas encore eu le temps de prendre possession de la mémoire fraîchement allouée, il n'aura pas la possibilité de la libérer. A ce problème, deux solutions :

Soit ne jamais créer de shared_ptr temporaires, en remplaçant le code précédent par :

int f(shared_ptr<int> i, int j);
int g();

shared_ptr<int> si (new int (42));
f(si, g());

Soit ne pas allouer de pointeur nu du tout, ce qui évite qu'ils puissent fuir (il faut le C++0x pour pouvoir faire ça) :

int f(shared_ptr<int> i, int j);
int g();
f(make_shared<int>(42), g());

Le plus gros problème à l'utilisation d'un shared_ptr est probablement qu'il ne gère pas correctement les cycles. Considérons le code suivant (dans du vrai code, les cycles seraient évidemment moins faciles à détecter) :

class A
{
    // ...
    shared_ptr<B> myB;
};

class B
{
    // ...
    shared_ptr<A> myA;
};
shared_ptr<A> a = new A;
shared_ptr<B> b = new B;
cout << a.use_count() << ", " << b.use_count() << endl;
a->myB = b;
cout << a.use_count() << ", " << b.use_count() << endl;
b->myA = a;
cout << a.use_count() << ", " << b.use_count() << endl;
a.reset();
b.reset();

Si l'on s'intéresse aux compteurs de référence de nos objets, on constate qu'à la première ligne, ils valent tous deux 1, rien de surprenant jusque là. À la seconde ligne d'affichage, ils valent respectivement 1 et 2. En effet, deux pointeurs pointent sur l'objet de type B : b, et a->myB. À la troisième ligne d'affichage, les valeurs sont toutes deux de 2.

Après les resets, les objets A et B sont devenus inaccessibles depuis notre code, mais myB dans l'objet de type A fait survivre l'objet de type B en maintenant son comptage de référence à 1, et myA dans ce dernier fait survivre l'objet de type A. Nos deux objets se font donc survivre mutuellement. Nous avons une fuite mémoire. C'est le principal défaut des shared_ptrs par rapport à un système comme un glaneur de cellules. La classe weak_ptr, qui fait l'objet du chapitre suivant, permet de s'en sortir dans ce genre de situations.

Il y a deux cas où l'on veut obtenir un shared_ptr à partir du pointeur nu this. Le premier, c'est dans une fonction membre d'une classe, si on a besoin d'appeler sur nous-mêmes une fonction externe à la classe qui prend en paramètre un shared_ptr (pour que ça marche, il faut bien entendu que l'on soit certain que l'objet courant est déjà géré par shared_ptr).

Il n'y a pas de solutions non intrusives à ce problème. Il faut modifier la classe afin qu'elle sache d'elle-même comment retrouver le shared_ptr lui correspondant. Pour ça, on fait dériver la classe d'une classe nommée enable_shared_from_this :

class A;
void registerA(shared_ptr<A> ptr);

class A : public enable_shared_from_this<A>
{
   void f()
   {
       registerA(shared_from_this());
   }
};

On remarque que enable_shared_from_this est un template, qui prend en paramètre template la classe même dans laquelle on veut obtenir cette fonctionnalité.

Le second cas est un peu particulier, c'est quand on veut obtenir la même chose, mais dans le constructeur de la classe. Le problème, c'est que lors de sa construction, l'objet n'est pas encore construit, et donc ne peut pas encore avoir été associé à un shared_ptr. Reprenons l'exemple précédent :

class A;
void registerA(shared_ptr<A> ptr);

class A
{
public:
   A()
   {
       registerA(???);
   }
};

La solution à ce problème est de modifier légèrement l'architecture du code, afin de passer par une factory au lieu de vouloir faire le travail dans un constructeur.

class A;
void registerA(shared_ptr<A> ptr);

class A
{
private:
    A() {}
public:
    static shared_ptr<A> create()
    {
        shared_ptr<A> result(new A);
        registerA(result);
        return result;
    }
};

Il y a des cas où l'on n'a pas créé un objet à l'aide de new, mais à l'aide d'une autre fonction. Par exemple, supposons que l'on utilise une bibliothèque qui nous permette de manipuler des Toto*, que l'on obtient et détruit à l'aide des fonctions suivantes :

Toto* createToto();
void deleteToto(Toto *t);

Si l'on écrit un simple shared_ptr<Toto>, quand il va vouloir détruire l'objet, il va appeler delete dessus, et non pas la fonction spécifique deleteToto. Est-ce à dire que l'on doit se passer de la sûreté et du confort des shared_ptrs dans ce cas ? Heureusement non, les shared_ptr ont un second argument dans leur constructeur qui permet de spécifier comment l'objet géré doit être détruit :

shared_ptr<Toto> createSafeToto()
{
    return shared_ptr<Toto> (createToto(), &deleteToto);
}

Il peut arriver qu'un utilisateur souhaite manipuler une sous-partie d'un objet par shared_ptr. Supposons une classe :

struct Voiture
{
    vector<Roue> mesRoues;
};

Supposons que nos voitures soient gérées par l'intermédiaire des shared_ptr, et intéressons-nous au code qui travaille avec les roues. On a envie que ce code influe sur la durée de vie d'une voiture, et que tant que ce code possède une roue, la voiture à laquelle la roue est attachée ne soit pas détruite.

On peut envisager plusieurs façons d'y parvenir. Par exemple, la roue peut avoir un shared_ptr sur sa voiture (attention aux boucles !). Une autre solution serait que le code gérant les roues prenne en paramètre des shared_ptr<Voiture>, mais ce n'est pas très propre, car ça introduit un couplage inutile entre ce code et le code de voiture (que faire par exemple si je veux utiliser le même code sur des roues en vrac non encore montées ?).

Finalement, les shared_ptr présentent une autre option, plus claire, à ce problème. L'idée est de spécifier un shared_ptr sur une sous-partie de l'objet, mais qui partage son comptage de référence avec l'objet dans sa totalité.

struct Voiture
{
    vector<Roue> mesRoues;
};

shared_ptr<Roue> getRoue(shared_ptr<Voiture> const &v, int id)
{
    // Premier argument : Où est mon comptage de référence
    // Second argument : Où est-ce que je pointe
    return shared_ptr<Roue>(v, &v->mesRoues[id]);
}

Le premier inconvénient des shared_ptrs, c'est qu'ils ne gèrent pas les cycles, on en a parlé.

Un second inconvénient peut être les performances. Sur deux points, ils sont moins performants que des pointeurs nus (mais ils apportent plus de choses, donc il ne faut pas conclure trop vite) :

• il y a besoin d'espace supplémentaire pour gérer le comptage de référence. De plus, cet espace peut demander une allocation mémoire supplémentaire lors de la création, sauf si la fonction make_shared (C++0x) est utilisée ;
• chaque opération de copie du pointeur doit incrémenter le compteur de référence, ce qui peut être assez coûteux dans un contexte multithread. Comparé à un glaneur de cellule, le coût est probablement comparable, selon l'usage qui en est fait, mais cette opération a lieu pendant l'opération elle-même, et non pendant un moment où le système attend, ce qui est plus perceptible.
  La move semantic offerte par C++0x (et qui commence à être disponible dans certains compilateurs (gcc par exemple) peut nettement réduire le nombre de ces coûteuses opérations de copie. En attendant cette fonctionnalité, certaines implémentations ont spécialisé certaines classes (comme vector<shared_ptr<T> > pour Visual C++/TR1) afin de minimiser ces copies dans des cas d'utilisation très courants.

Il est possible de créer un weak_ptr soit à partir d'un shared_ptr, soit à partir d'un autre weak_ptr. Contrairement à shared_ptr, il n'est pas possible d'en créer un à partir d'un pointeur nu, un weak_ptr n'étant là que pour travailler en collaboration avec un shared_ptr.

La première grosse différence que l'on voit entre les deux types de pointeurs à l'utilisation, c'est que weak_ptr n'est pas vraiment un pointeur intelligent, il lui manque en effet une surcharge de l'opérateur ->.

Le mode d'emploi pour accéder à l'objet pointé est de créer un shared_ptr à partir du weak_ptr, et de travailler à partir de ce nouveau pointeur. Pour ça, deux méthodes sont possibles, le constructeur de shared_ptr prenant un weak_ptr en paramètre et la fonction lock (qui est souvent plus explicite):

void f(weak_ptr<T> weakData)
{
    shared_ptr<T> sharedData = weakData.lock();
    // ou : shared_ptr<T> sharedData(weak_data);
    if (sharedData)
    {
        sharedData->onPeutTravaillerAvec();
    }
    else
    {
        // l'objet pointé a été détruit
    }
}

Pour quelle raison cette obligation ? Imaginons l'espace d'un instant qu'on puisse travailler directement avec un weak_ptr :

void f(weak_ptr<T> weakData)
{
    if (weakData.expired())
    {
        // l'objet pointé a été détruit, c'est le 
        // rôle de la fonction expired de nous en avertir
    }
    else
    {
        weakData->onPeutTravaillerAvec(); // ?
    }
}

Dans un environnement multithread, ce code qui semble pourtant bien intentionné peut avoir un problème si l'objet est détruit entre le moment où on teste expired et le moment où l'on appelle la fonction.

Qu'à cela ne tienne, diront certains, il suffit que l'opérateur -> teste si l'objet existe encore, et lance une exception si ce n'est pas le cas, en mettant les verrous qui vont bien pour que l'objet survive le temps que l'on appelle l'opérateur->. Mais même là, ça ne marche pas : Au moment où la fonction onPeutTravaillerAvec() est appelée, le code de l'opérateur -> a totalement fini de s'exécuter, et rien n'empêche donc l'objet d'être détruit alors qu'on travaille dessus.

Le passage par un shared_ptr permet donc, si le comptage de référence est sur le point de passer à 0 dans un autre thread, de prolonger la durée de vie de l'objet pointé le temps qu'on en ait fini avec lui.

En pratique, l'utilisation de expired, tout comme de use_count est très rare, et, sauf pour du code de test ou de débogage indique probablement une mauvaise compréhension du fonctionnement du code en multithread.

Quand on a une boucle entre deux objets A et B, deux solutions sont possibles pour la casser. Donner à A un shared_ptr sur B, et à B un weak_ptr sur A, ou l'inverse. Il y a des cas où l'ordre dans lequel le pointeur doit être fort ou faible apparaît comme évident, d'autres moins.

En particulier, dans le cas de collection, j'ai vu des gens argumenter (très) longuement sur le sujet. Supposons par exemple un tiroir rempli de chaussettes, chaque chaussette ayant besoin de savoir où elle est rangée.

Première possibilité :

struct Tiroir
{
    vector<shared_ptr<Chaussette> > monContenu;
};
struct Chaussette
{
    weak_ptr<Tiroir> monTiroir;
};

Seconde possibilité :

struct Tiroir
{
    vector<weak_ptr<Chaussette> > monContenu;
};
struct Chaussette
{
    shared_ptr<Tiroir> monTiroir;
};

La première possibilité paraît souvent plus naturelle, et reproduit l'idée assez logique que si l'on jette un tiroir à la poubelle, on a automatiquement jeté les chaussettes qu'il contient (sauf une chaussette qui serait tenue par quelqu'un d'autre). La seconde approche part plutôt du mode de pensée que tant qu'on utilise une chaussette, il faut pouvoir la ranger, et donc le tiroir doit survivre tant qu'il lui reste une chaussette.

Les deux points de vue ont des arguments, et le bon choix réside probablement dans la manière dont le programme compte utiliser tiroir et chaussettes.

L'une des principales utilisations de unique_ptr est de mettre en place le RAII pour des classes pas forcément prévues pour ça. À cette fin, on utilisera assez souvent les possibilités de spécifier la fonction de désallocation, qui sont les mêmes que pour shared_ptr.

void *createProcess();
void deleteProcess(void *p);

void travailleAvecUnNouveauProcessus()
{
    unique_ptr<void> process(createProcess(), &deleteProcess);
    // on peut travailler avec p, il sera automatiquement
    // détruit quand on quittera la fonction.
}

Il y a principalement deux avantages. Le premier est en termes de performance. unique_ptr ne demande pas de compteur de référence, c'est un pointeur très léger.

Le second est en termes de documentation de code. Les cas d'utilisation d'un unique_ptr et ceux d'un shared_ptr sont en fait assez différents, et il est pratique d'avoir une classe qui indique clairement au lecteur du code dans quel cas on se trouve.