Discussion :

[poporiding]

bonjour tout le monde,

ma question est surement bete, mais je n'ai pas trouvé d'exemple ou d'aide sur internet.
Mon problème est sur le destructeur d'une classe. je ne vois pas trop ce qu'il faut mettre dans le code d'un destructeur.
delete this;?
delete de chaque donnée membres ...?
doit on utiliser un delete? sachant que le delete appel lui aussi le destructeur ...

[Médinoc]

delete sur chaque donnée membre créée avec new.

Et généralement, si tu ne fais que du C++, rien de plus.
(Si tu utilisais des fichiers C dans ta classe par exemple, tu pourrais avoir besoin d'un close(), etc.)

[poporiding]

Aucunne de mes donnée menbre n'est créée avec un new, c'est que des int, short char.

je dois donc rien mettre dans le destructeur?

[Médinoc]

On dirait bien.

[poporiding]

et comme je créé une fonction avec auccun code a l'intérieur a t'elle réellement besoin d'exister?

[Eusebe]

Non, tu n'es pas obligé de la créer, elle l'est automatiquement.

Maintenant, une bonne habitude, c'est de la déclarer quand même (tout en la laissant vide). Cela permet au moins de savoir que tu y as réfléchi...

[Alp]

Juste un truc : vérifies que tu as bien fermé toutes tes sources de données : fichiers, connexions à des BDD, ...

[Luc Hermitte]

Il y a quelques cas particuliers où expliciter le destructeur est nécessaire
- pour les classes dans des hiérarchies polymorphes, le destructeur doit être virtuel et public pour permettre la destruction polymorphique
- pour les classes de base ("base" comme dans héritage) de hiérarchies non polymorphes qui apportent du code. Il peut être bon d'avoir le destructeur explicité non virtuel mais protégé
- pour les classes qui ont des membres dont le destructeur inliné fait un appel explicite à une fonction qui peut se comporter différemment d'une unité de traduction (ou d'une bibliothèque) à l'autre -- typiquement pour quand new/delete sont supplantés dans une UT ou dans une lib. Typiquement, si ta classe contient un auto_ptr<>, il vaut mieux lui adjoindre un destructeur non inliné. En fait il faudrait procéder encore autrement en attachant la fonction de libération au pointeur intelligent au moment de la construction.


Je me doute bien que tout ceci te passe largement au dessus de la tête.
Retiens que si tu gères manuellement une ressource dont tu es responsable, alors il faut toujours la libérer à ta mort => dans ton destructeur.
Une des règles (pour avoir un code simple, juste et maintenable) est de ne jamais être directement responsable de plus d'une seule ressource. Cf l'entrée sur le RAII dans la FAQ.

PS: le destructeur d'un objet est appelé qunad tu appelles delete sur un pointeur vers ton objet, où quand ton objet était sur la pile et que l'on sort de la portée dans laquelle il vivait. => n'appelle jamais delete sur this dans un destructeur. A moins de vouloir partir en boucle qui aurait pu être infinie si elle ne faisait pas planter le programme immédiatement.

[Clad3]

Dans le même genre, j'ai il y a peu qu'il était inutile, voir nuisible d'implémenter et de déclarer explicitement le destructeur d'une classe si celui-ci est destiné a être "vide" , et que dans ce cas, le compilateur ferai un meilleur travail a notre place . Je ne vois pas trop comment ni pourquoi, alors info ou intox ?

[JolyLoic]

Inutile ? sûrement. Nuisible ? Le seul code où je suis à peu près sur de ne pas faire d'erreur, c'est le code que je n'écris pas. Donc oui. C'est du travail bête et méchant, du travail de compilateur, pas de développeur.

De plus, en général, quand je vois un destructeur, je me pose automaitquement des questions sur le contructeur par recopie et l'opératuer d'affectation. Si le destructeur est "vide", c'est inutile, mais j'ai peut-être perdu un peu de temps à la lecture.

Enfin, le destructeur par défaut est déclaré inline, le tiens, ça dépend. Est-ce qu'il y a un impact, j'en doute très fortement. Je n'ai jamais effectué de mesure.

Donc, en gros, rien de bien grave, mais je préfère ne rien mettre.

Attention : Je ne parle bien évidemment pas ici du fait de déclarer un destructeur virtuel pour une classe de base d'une hiérarchie polymorphe, qui est très important, qu'il soit vide ou non.