Wann sollten Sie keine virtuellen Destruktoren verwenden?

Question

Gibt es jemals einen guten Grund für pas einen virtuellen Destruktor für eine Klasse deklarieren? Wann sollten Sie es ausdrücklich vermeiden, einen zu schreiben?

Answer 1

Es besteht keine Notwendigkeit, einen virtuellen Destruktor zu verwenden, wenn einer der folgenden Punkte zutrifft:

• Keine Absicht, daraus Klassen abzuleiten
• Keine Instanziierung auf dem Heap
• Keine Absicht zur Speicherung mit Zugriff über einen Zeiger auf eine Oberklasse

Es gibt keinen besonderen Grund, es zu vermeiden, es sei denn, Sie haben wirklich einen großen Speicherbedarf.

Answer 2

Um die Frage explizit zu beantworten, d.h. wann sollten Sie no einen virtuellen Destruktor deklarieren.

C++ '98/'03

Das Hinzufügen eines virtuellen Destruktors kann dazu führen, dass Ihre Klasse nicht mehr als POD (einfache alte Daten) * oder als Aggregat zu Nicht-POD. Dies kann dazu führen, dass Ihr Projekt nicht mehr kompiliert werden kann, wenn Ihr Klassentyp irgendwo als Aggregat initialisiert ist.

struct A {
  // virtual ~A ();
  int i;
  int j;
};
void foo () { 
  A a = { 0, 1 };  // Will fail if virtual dtor declared
}

Im Extremfall kann eine solche Änderung auch zu undefiniertem Verhalten führen, wenn die Klasse in einer Weise verwendet wird, die ein POD erfordert, z. B. bei der Übergabe über einen Ellipsis-Parameter oder bei der Verwendung mit memcpy.

void bar (...);
void foo (A & a) { 
  bar (a);  // Undefined behavior if virtual dtor declared
}

[Ein POD-Typ ist ein Typ, der bestimmte Garantien für sein Speicherlayout hat. Der Standard besagt eigentlich nur, dass, wenn man von einem Objekt mit POD-Typ in ein Array von Zeichen (oder Zeichen ohne Vorzeichen) und wieder zurück kopiert, das Ergebnis dasselbe sein wird wie das ursprüngliche Objekt.]

Modernes C++

In neueren Versionen von C++ wurde das Konzept des POD zwischen dem Klassenlayout und dessen Konstruktion, Kopieren und Zerstörung aufgeteilt.

Für den Fall der Ellipse ist es nicht mehr undefiniertes Verhalten, sondern wird nun bedingt unterstützt mit implementierungsdefinierter Semantik (N3937 - ~C++ '14 - 5.2.2/7):

...Die Übergabe eines potentiell bewerteten Arguments vom Typ Klasse (Klausel 9) mit einem nicht-trivialen Kopierkonstruktor, einem nicht-trivialen Verschiebekonstruktor oder einem nicht-trivialen Destruktor ohne entsprechenden Parameter wird mit implementierungsdefinierter Semantik bedingt unterstützt.

Die Deklaration eines anderen Destruktors als =default wird bedeuten, dass es nicht trivial ist (12.4/5)

... Ein Destruktor ist trivial, wenn er nicht vom Benutzer zur Verfügung gestellt wird ...

Andere Änderungen an Modern C++ verringern die Auswirkungen des Problems der Aggregatinitialisierung, da ein Konstruktor hinzugefügt werden kann:

struct A {
  A(int i, int j);
  virtual ~A ();
  int i;

  int j;
};
void foo () { 
  A a = { 0, 1 };  // OK
}

Answer 3

Ich deklariere einen virtuellen Destruktor, wenn und nur wenn ich virtuelle Methoden habe. Sobald ich virtuelle Methoden habe, vertraue ich nicht darauf, dass ich es vermeide, sie auf dem Heap zu instanziieren oder einen Zeiger auf die Basisklasse zu speichern. Beides sind sehr häufig vorkommende Operationen, die oft unbemerkt Ressourcen verschwinden lassen, wenn der Destruktor nicht als virtuell deklariert ist.

Answer 4

Ein virtueller Destruktor wird immer dann benötigt, wenn die Möglichkeit besteht, dass delete könnte auf einen Zeiger auf ein Objekt einer Unterklasse mit dem Typ Ihrer Klasse aufgerufen werden. Dadurch wird sichergestellt, dass der richtige Destruktor zur Laufzeit aufgerufen wird, ohne dass der Compiler die Klasse eines Objekts auf dem Heap zur Kompilierzeit kennen muss. Nehmen wir zum Beispiel an B ist eine Unterklasse von A :

A *x = new B;
delete x;     // ~B() called, even though x has type A*

Wenn Ihr Code nicht leistungskritisch ist, wäre es vernünftig, jeder Basisklasse, die Sie schreiben, einen virtuellen Destruktor hinzuzufügen, nur zur Sicherheit.

Wenn Sie jedoch feststellen, dass Sie delete Wenn man viele Objekte in einer engen Schleife aufruft, kann der Performance-Overhead des Aufrufs einer virtuellen Funktion (selbst einer leeren) spürbar sein. Der Compiler kann diese Aufrufe in der Regel nicht einbinden, und für den Prozessor ist es unter Umständen schwierig, vorherzusagen, wohin er gehen soll. Es ist unwahrscheinlich, dass dies einen signifikanten Einfluss auf die Leistung hat, aber es ist erwähnenswert.

Answer 5

Nicht alle C++-Klassen sind für die Verwendung als Basisklasse mit dynamischer Polymorphie geeignet.

Wenn Ihre Klasse für dynamische Polymorphie geeignet sein soll, muss ihr Destruktor virtuell sein. Darüber hinaus müssen alle Methoden, die eine Unterklasse möglicherweise überschreiben möchte (d. h. alle öffentlichen Methoden sowie möglicherweise einige intern verwendete geschützte Methoden), virtuell sein.

Wenn Ihre Klasse nicht für dynamische Polymorphie geeignet ist, sollte der Destruktor nicht als virtuell gekennzeichnet werden, da dies irreführend ist. Es ermutigt die Leute nur, Ihre Klasse falsch zu verwenden.

Hier ein Beispiel für eine Klasse, die sich nicht für dynamische Polymorphie eignet, selbst wenn ihr Destruktor virtuell wäre:

class MutexLock {
    mutex *mtx_;
public:
    explicit MutexLock(mutex *mtx) : mtx_(mtx) { mtx_->lock(); }
    ~MutexLock() { mtx_->unlock(); }
private:
    MutexLock(const MutexLock &rhs);
    MutexLock &operator=(const MutexLock &rhs);
};

Der ganze Sinn dieses Kurses ist es, sich auf den Stapel für RAII zu setzen. Wenn Sie Zeiger auf Objekte dieser Klasse weitergeben, ganz zu schweigen von deren Unterklassen, dann machen Sie etwas falsch.