| ||
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 :
| ||
lien : Qu'est-ce qu'un constructeur ? |
| ||
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 :
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é. |
| ||
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 :
|
| ||
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] :
|
| ||
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.
|
| ||
auteur : Marshall Cline | ||
Il suffit de limiter la durée de vie de l'objet local en le plaçant dans un bloc { ... } artificiel :
|
| ||
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 :
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é).
|
| ||
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 :
Le destructeur Fred::~Fred() va être appelé automatiquement quand vous utiliserez delete
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.
|
| ||
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.
|
| ||
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 bases sont détruites après les objets membres. Et dans le cas d'un héritage multiple, les classes de bases directes sont détruites dans l'ordre inverse de celui dans lequel elles apparaissent dans la déclaration d'héritage.
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.
|
| ||
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 :
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.
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 terme 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. |
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.