Ce destructeur C ++ est-il redondant?

J’ai reçu du code C ++ avec différentes structures définies comme suit:

typedef struct _someStruct_ { std::ssortingng someSsortingng; std::vector someVectorOfSsortingngs; int someOtherStuff; ~_someStruct_() { someSsortingng.clear(); someVectorOfSsortingngs.clear(); } } someStruct; 

Le destructeur est-il ici complètement redondant – si la structure devait être détruite par le destructeur par défaut, les chaînes, vecteurs, etc. ne seraient-ils pas détruits de toute façon?

Si j’avais écrit le code, je n’aurais pas pensé à append un destructeur explicite ici – je laisserais simplement le compilateur s’en charger.

Si je comprends bien, le seul moment où vous pourriez avoir besoin de créer votre propre destructeur dans une structure est si l’un des membres de la structure contient des pointeurs vers des données qui pourraient nécessiter un nettoyage ou des fonctionnalités supplémentaires (par exemple pour le débogage, la journalisation). une structure est supprimée) est nécessaire.

Est-ce que je manque quelque chose ici – y a-t-il une raison pour laquelle les chaînes et les vecteurs ont été explicitement effacés dans le destructeur? Mon soupçon est que la personne qui m’a envoyé ceci est vraiment un programmeur C (cf. le typedef) qui a essayé de transformer du code C en C ++.

Oui, le destructeur est complètement redondant.

Comme vous l’avez dit vous-même, le code comporte d’autres signes d’avertissement. L’utilisation de typedef struct par exemple n’a aucun sens en C ++, elle est aussi redondante que le destructeur vide: le code a été écrit par quelqu’un avec une connaissance limitée de C ++, il y a forcément plus de pièges (le nom de la classe est invalide) en raison du soulignement de premier plan dans la scope mondiale).

En fait, c’est pire que d’utiliser simplement le destructeur implicite.

En ayant le destructeur explicite, le compilateur ne vous fournira pas de constructeur de déplacement implicite!

Le destructeur est presque complètement redondant.

Il fait trois choses.

Tout d’abord, il bloque la création automatique de constructeurs et d’affectations copier / déplacer. Ce n’est peut-être pas une bonne chose. Mais peut-être est-ce souhaitable. Ce n’est cependant pas la même chose que de ne pas être là.

Deuxièmement, il modifie l’ordre dans lequel les éléments sont nettoyés. Le tampon contenu dans la chaîne est effacé, puis chaque tampon contenu dans les chaînes du vecteur est détruit pendant que la chaîne les contenant est détruite, puis le vecteur contenant un tampon inutilisé. la mémoire est détruite (retourne la mémoire), puis la chaîne maintenant vide est détruite.

Avec un destructeur par défaut, l’ordre est que les tampons de la chaîne du vecteur sont détruits, puis la mémoire des chaînes du vecteur est renvoyée pendant que le vecteur est détruit, puis la chaîne est détruite avec son tampon renvoyé.

Vous pourriez détecter cela avec des surcharges appropriées à l’opérateur new & delete ou si vous avez utilisé des allocateurs personnalisés.

Enfin, de tels destructeurs peuvent parfois être plus faciles à déboguer, car vous pouvez les parcourir.

Les chances sont, cependant, qu’aucun de ces effets subtils ne soit prévu par le développeur qui a écrit ce code.