Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

Vous n'avez pas encore de compte Developpez.com ? L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Developpez.com

C++

Choisissez la catégorie, puis la rubrique :

logo
Sommaire > Les classes en C++ > Les destructeurs
        Qu'est-ce qu'un destructeur ?
        Est-il possible d'invoquer explicitement le destructeur d'une classe ?
        Dans quel ordre les objets locaux sont-ils détruits ?
        Dans quel ordre les objets contenus dans un tableau sont-ils détruits ?
        Doit-on détruire explicitement les objets locaux ?
        Et si on veut absolument qu'un objet local 'meure' avant l'accolade fermant le bloc dans lequel il a été créé ?
        Et s'il n'est pas possible de placer l'objet local dans un bloc artificiel ?
        Peut-on détruire explicitement un objet alloué par new ?
        Dans le code d'un destructeur, doit-on détruire explicitement les objets membres ?
        Dans le code du destructeur d'une classe dérivée, doit-on appeler explicitement le destructeur de la classe de base ?
        Pourquoi et quand faut-il créer un destructeur virtuel ?



Qu'est-ce qu'un destructeur ?
Mise à jour le 15/05/2003[haut]
auteur : LFE
Un destructeur est ce qui détruit un objet, libère la mémoire allouée dans le constructeur ou ce qui n'a pas été libéré durant la vie de l'objet.
Il porte le même nom que la classe précédé du signe ~.
Un destructeur ne prend aucun paramètre et ne renvoie aucune valeur de retour. Sa déclaration se fait de la façon suivante :
class MaClasse
{
    // ... 
    ~MaClasse();
};
lien : Qu'est-ce qu'un constructeur ?

Est-il possible d'invoquer explicitement le destructeur d'une classe ?
Mise à jour le 22/11/2004[haut]
auteurs : LFE, Laurent Gomila, Aurélien Regat-Barrel
Oui, il est possible d'appeler explicitement le destructeur d'une classe, bien que ce soit une pratique à proscrire. La raison en est simple : il est appelé automatiquement par le compilateur lorsque l'objet va être détruit, et ce, que vous l'ayez appelé ou non. Autrement dit, dans le code suivant :
#include <iostream>

class Test
{
public:
    ~Test() { std::cout << "Destruction\n"; }
};

int main()
{
    Test t;
    t.~Test(); // appelle explicite du destructeur
} // ici, le compilateur appelle à nouveau le destructeur
le destructeur est appelé 2 fois. En fonction de ce qu'il fait, cela peut avoir des conséquences dramatiques. Mais surtout cela ne sert à rien puisque c'est le travail du compilateur.
L'un des seuls cas où l'on doit appeler le destructeur explicitement est lorsqu'on a utilisé l'opérateur new de placement pour créer le même objet. Dans ce cas, de même qu'on s'est substitué au compilateur pour gérer la vie de l'objet, il faut faire le travail jusqu'au bout et gérer sa destruction. Voir à ce sujet Qu'est-ce que 'placement new' et dans quels cas l'utilise-t-on ?.
Il y a aussi des fois où l'on est obligé de le faire, comme quand on développe avec un ancien compilateur qui faillit à son devoir et n'appelle pas le destructeur sur les objets statiques. Dans ce cas aussi l'appel explicite au destructeur est justifié.


Dans quel ordre les objets locaux sont-ils détruits ?
Créé le 19/03/2004[haut]
auteur : Marshall Cline
Dans l'ordre inverse de celui dans lequel ils ont été construits : le premier objet construit est le dernier détruit.

Dans l'exemple ci-dessous, le destructeur de b sera exécuté en premier, suivi du destructeur de a :
void userCode()
{
    Fred a;
    Fred b;
    // ...
}

Dans quel ordre les objets contenus dans un tableau sont-ils détruits ?
Créé le 19/03/2004[haut]
auteur : Marshall Cline
Dans l'ordre inverse de celui dans lequel ils ont été construits : le premier objet construit est le dernier détruit.

Dans l'exemple ci-dessous, l'ordre des destructions est a[9], a[8], ..., a[1], a[0] :
void userCode()
{
    Fred a[10];
    // ...
}

Doit-on détruire explicitement les objets locaux ?
Créé le 19/03/2004[haut]
auteur : Marshall Cline
Surtout pas !

Car le destructeur sera appelé une deuxième fois au niveau de l'accolade fermant le bloc dans lequel l'objet a été créé. La norme C++ le garantit et vous ne pouvez rien faire pour empêcher que ça arrive ; c'est automatique. Et ça risque de vraiment très mal se passer si le destructeur d'un objet est appelé deux fois de suite.


Et si on veut absolument qu'un objet local "meure" avant l'accolade fermant le bloc dans lequel il a été créé ?
Créé le 19/03/2004[haut]
auteur : Marshall Cline
Il suffit de limiter la durée de vie de l'objet local en le plaçant dans un bloc { ... } artificiel :
void someCode()
{
    {
        File f;
        // ... [Ici, le fichier est encore ouvert] ...
    }
    // ^? Ici, le destructeur de f est appelé automatiquement !
    // ^— Ici, le destructeur de f est appelé automatiquement !
    
    // ... [Le code ici s'exécutera après que f soit fermé]  ...
}

Et s'il n'est pas possible de placer l'objet local dans un bloc artificiel ?
Créé le 19/03/2004[haut]
auteur : Marshall Cline
Dans la plupart des cas, il est possible de limiter la durée de vie d'un objet local en le plaçant dans un bloc artificiel ({ ... }) . Si, pour une raison ou pour une autre, ce n'est pas possible, ajoutez à la classe une fonction membre qui a le même effet que le destructeur. Mais n'appelez pas le destructeur vous-même !

Dans le cas de File, par exemple, vous pourriez ajouter à la classe une fonction membre close(). Le destructeur se contenterait simplement d'appeler cette fonction. Notez que la fonction close() aura besoin de marquer l'objet File de façon à ne pas tenter de fermer le fichier s'il l'est déjà, ce qui peut se produire si close() est appelée plusieurs fois. L'une des solutions possibles est de donner à la donnée membre fileHandle_ une valeur qui n'a pas de sens, par exemple -1, et de vérifier à l'entrée de la fonction que fileHandle_ n'est pas égale à cette valeur :
class File {
    public:
      void close();
      ~File();
       // ...
    private:
      int fileHandle_;    //  fileHandle_ >= 0 seulement si le fichier est ouvert
    };
    
    File::~File()
    {
      close();
    }
    
    void File::close()
    {
      if (fileHandle_ >= 0) {
         // ... [Utiliser les appels systèmes qui conviennent pour fermer le fichier] ...
        fileHandle_ = -1;
      }
}
Notez que les autres fonctions membres de la classe File peuvent elles aussi avoir besoin de vérifier que fileHandle_ n'est pas égale à -1 (c'est-à-dire, de vérifier que le fichier n'est pas fermé).


Peut-on détruire explicitement un objet alloué par new ?
Créé le 19/03/2004[haut]
auteur : Marshall Cline
Dans la plupart des cas, NON.

À moins que vous ayez utilisé placement new, utilisez delete plutôt que d'appeler explicitement le destructeur de l'objet. Imaginez par exemple que vous ayez alloué un objet grâce à une "new expression" classique :
Fred* p = new Fred();
Le destructeur Fred::~Fred() va être appelé automatiquement quand vous utiliserez delete
delete p; // p->~Fred() est appelé automatiquement
N'appelez pas explicitement le destructeur, car cela ne libèrera pas la mémoire allouée pour l'objet Fred lui-même. Gardez à l'esprit que delete p a deux effets : il appelle le destructeur et il désalloue la mémoire.


Dans le code d'un destructeur, doit-on détruire explicitement les objets membres ?
Créé le 19/03/2004[haut]
auteur : Marshall Cline
Non. Il n'est jamais nécessaire d'appeler explicitement un destructeur (sauf si l'objet a été créé avec un placement new).

Le destructeur d'une classe (il existe même si vous ne l'avez pas défini) appelle automatiquement les destructeurs des objets membres. Ces objets sont détruits dans l'ordre inverse de celui dans lequel ils apparaissent dans la déclaration de la classe.
class Member {
    public:
      ~Member();
       // ...
};
    
class Fred {
    public:
      ~Fred();
       // ...
    private:
      Member x_;
      Member y_;
      Member z_;
};
    
Fred::~Fred()
{
    // Le compilateur appelle automatiquement  z_.~Member()
    // Le compilateur appelle automatiquement  y_.~Member()
    // Le compilateur appelle automatiquement  x_.~Member()
}

Dans le code du destructeur d'une classe dérivée, doit-on appeler explicitement le destructeur de la classe de base ?
Créé le 19/03/2004[haut]
auteur : Marshall Cline
Non. Il n'est jamais nécessaire d'appeler explicitement un destructeur (sauf si l'objet a été créé avec un placement new).

Le destructeur d'une classe dérivée (il existe même si vous ne l'avez pas défini) appelle automatiquement les destructeurs des sous-objets des classes de base. Les classes de base sont détruites après les objets membres. Et dans le cas d'un héritage multiple, les classes de base directes sont détruites dans l'ordre inverse de celui dans lequel elles apparaissent dans la déclaration d'héritage.
class Member {
   public:
      ~Member();
       // ...
};
    
class Base {
   public:
      virtual ~Base();      // Un destructeur virtuel 
       // ...
};
    
class Derived : public Base {
   public:
      ~Derived();
       // ...
   private:
      Member x_;
};
    
Derived::~Derived()
{
    // Le compilateur appelle automatiquement x_.~Member()
    // Le compilateur appelle automatiquement Base::~Base()
}
Note : l'ordre des destructions dans le cas d'un héritage virtuel est plus compliqué. Si vous voulez vous baser sur l'ordre des destructions dans le cas d'un héritage virtuel, il va vous falloir plus d'informations que celles simplement contenues dans cette FAQ.


Pourquoi et quand faut-il créer un destructeur virtuel ?
Créé le 22/11/2004[haut]
auteur : Aurélien Regat-Barrel
Il est nécessaire de rendre le destructeur d'une classe de base virtuel quand celle-ci est destinée à être détruite polymorphiquement. Généralement dès qu'un objet commence à être utilisé polymorphiquement (c'est-à-dire utilisé en place d'un objet de la classe mère), il est fréquent qu'il soit stocké et manipulé via un pointeur vers sa classe mère, comme dans l'exemple suivant :
#include <iostream>

// classe de base A destinée à être dérivée
class A
{
public:
    A() { std::cout << "Constructeur de A.\n"; }
    ~A() { std::cout << "Destructeur de A.\n"; }

    virtual void PrintName() { std::cout << "Classe A.\n"; }
};

// B hérite de A
class B : public A
{
public:
    B() { std::cout << "Constructeur de B.\n"; }
    ~B() { std::cout << "Destructeur de B.\n"; }

    virtual void PrintName() { std::cout << "Classe B.\n"; }
};

int main()
{
    // utilisation polymorphe de B
    A * a = new B; // construction de A et B
    a->PrintName(); // affiche "Classe B"
    delete a; // destruction de A mais pas de B !
}
Si vous avez compris comment fonctionne les fonctions membres virtuelles (voir Que signifie le mot-clé virtual ?), vous pouvez alors deviner ce que l'instruction delete a; provoque : la destruction d'un objet de type A, donc l'appel de A::~A(), et de rien d'autre. Or, le type réel de notre objet est B, et donc son destructeur n'est pas appelé ! Ceci produit un comportement indéfini, qui se traduit souvent par des fuites de mémoires ou des problèmes encore plus graves (tout dépend de ce que le destructeur de B était censé faire).
Le code précédent compilé avec Visual C++ 7.1 produit le résultat suivant :

Constructeur de A. Constructeur de B. Classe B. Destructeur de A.

Comme vous pouvez le constater, le destructeur de B n'est effectivement pas appelé. Ceci est résolu en rendant le destructeur de A virtuel.
class A
{
public:
    A() { std::cout << "Constructeur de A.\n"; }
    virtual ~A() { std::cout << "Destructeur de A.\n"; }

    virtual void PrintName() { std::cout << "Classe A.\n"; }
};
Dans un tel cas d'utilisation, il est donc important de ne pas oublier le destructeur virtuel dans la classe de base. Cela ne signifie pas pour autant qu'il faille rendre tous les destructeurs virtuels. Tout d'abord une fonction membre virtuelle engendre un surcoût lors de son appel ainsi qu'en termes de d'occupation mémoire. Mais aussi un destructeur virtuel indique que la classe a été réalisée dans le but d'être dérivée.
Rendre un destructeur virtuel ou non ne se limite donc pas à l'ajout du mot-clé virtual mais doit être l'aboutissement d'une réflexion menée sur l'utilisation de la classe. Une classe qui n'est pas destinée à être dérivée n'a pas à avoir de destructeur virtuel.



Consultez les autres F.A.Q.


Valid XHTML 1.0 TransitionalValid CSS!

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2008 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Contacter le responsable de la rubrique C++

Partenaire : Hébergement Web