surcharge par défaut du destructeur virtuel

Question

Tout le monde sait que le destructeur de la classe de base doit généralement être virtuel. Mais qu'en est-il du destructeur de la classe dérivée ? En C++11, nous avons le mot-clé "override" et la possibilité d'utiliser explicitement le destructeur par défaut.

struct Parent
{
  std::string a;
  virtual ~Parent()
  {
  }

};

struct Child: public Parent
{
  std::string b;
  ~Child() override = default;
};

Est-il correct d'utiliser les deux mots-clés "override" et "=default" dans le destructeur de la classe Child ? Le compilateur générera-t-il un destructeur virtuel correct dans ce cas ?

Si oui, alors pouvons-nous penser que c'est un bon style de codage, et que nous devrions toujours déclarer les destructeurs des classes dérivées de cette façon pour s'assurer que les destructeurs des classes de base sont virtuels ?

Answer 1

Est-il correct d'utiliser les deux mots-clés "override" et "=default" dans le destructeur de la classe Child ? Le compilateur générera-t-il un destructeur virtuel correct dans ce cas ?

Oui, c'est correct. Sur n'importe quel compilateur sain d'esprit, si le code compile sans erreur, cette définition du destructeur sera un no-op : son absence ne doit pas changer le comportement du code.

peut-on penser que c'est un bon style de codage ?

C'est une question de préférence. Pour moi, cela n'a de sens que si le type de la classe de base est modélisé : cela imposera à la classe de base d'avoir un destructeur virtuel. Sinon, lorsque le type de base est fixe, je considérerais ce code comme du bruit. Ce n'est pas comme si la classe de base allait changer par magie. Mais si vous avez des coéquipiers qui aiment changer les choses sans vérifier le code qui dépend de ce qu'ils sont susceptibles de casser, il est préférable de laisser la définition du destructeur - comme une couche supplémentaire de protection.

Answer 2

override n'est rien de plus qu'un filet de sécurité. Le destructeur de la classe enfant sera toujours virtuel si le destructeur de la classe de base est virtuel, quelle que soit la façon dont il est déclaré - ou pas déclaré du tout (c'est-à-dire en utilisant un destructeur implicitement déclaré).

Answer 3

Il y a (au moins) une raison pour utiliser override ici -- vous vous assurez que le destructeur de la classe de base est toujours virtuel. Il y aura une erreur de compilation si le destructeur de la classe dérivée croit qu'il surcharge quelque chose, mais il n'y a rien à surcharger. Cela vous donne également un endroit pratique pour laisser la documentation générée, si vous le faites.

D'un autre côté, Je vois deux raisons de ne pas le faire :

• C'est un peu bizarre et arriéré pour la classe dérivée d'imposer le comportement de la classe de base.

• Si vous définissez un destructeur dans l'en-tête (ou si vous le mettez en ligne), vous introduisez la possibilité d'erreurs de compilation bizarres. Disons que votre classe ressemble à ceci :

  struct derived {
      struct impl;
      std::unique_ptr<derived::impl> m_impl;
      ~derived() override = default;
  };

  Vous obtiendrez probablement une erreur de compilation car le destructeur (qui est en ligne avec la classe ici) cherchera le destructeur de la classe incomplète, derived::impl .

  C'est ma façon détournée de dire que chaque ligne de code peut devenir un handicap, et qu'il est peut-être préférable d'ignorer quelque chose si cela ne sert à rien. Si vous avez vraiment besoin d'imposer un destructeur virtuel dans la classe de base de la classe parente, quelqu'un a suggéré d'utiliser static_assert de concert avec std::has_virtual_destructor qui produira des résultats plus cohérents, à mon avis.

Answer 4

Je pense que "override" est un peu trompeur sur destructor. Quand vous surchargez une fonction virtuelle, vous la remplacez. Les destructeurs sont enchaînés, donc vous ne pouvez pas surcharger destructeur littéralement.

Answer 5

El Référence CPP dit que override s'assure que la fonction est virtual et qu'elle remplace effectivement une fonction virtuelle. Ainsi, le override permet de s'assurer que le destructeur est virtuel.

Si vous spécifiez override mais pas = default alors vous obtiendrez une erreur d'édition de liens.

Vous n'avez rien à faire. En laissant le Child dtor undefined fonctionne très bien :

#include <iostream>

struct Notify {
    ~Notify() { std::cout << "dtor" << std::endl; }
};

struct Parent {
    std::string a;
    virtual ~Parent() {}
};

struct Child : public Parent {
    std::string b;
    Notify n;
};

int main(int argc, char **argv) {
    Parent *p = new Child();
    delete p;
}

Cela donnera dtor . Si vous retirez le virtual à l'adresse Parent::~Parent Cependant, il ne produira rien car il s'agit d'un comportement non défini, comme indiqué dans les commentaires.

Un bon style serait de ne pas mentionner Child::~Child du tout. Si vous ne pouvez pas avoir confiance dans le fait que la classe de base l'a déclarée virtuelle, alors votre proposition de override y = default fonctionnera ; j'espère qu'il existe de meilleures façons de s'en assurer, au lieu d'encombrer votre code de ces déclarations de destructeurs.