C++-Destruktoren erklärt: ~Klassenname, RAII, Aufräumen

Was ein Destruktor ist

Auf der vorherigen Seite hast du Konstruktoren gesehen - spezielle Funktionen, die laufen, wenn ein Objekt geboren wird, um seinen Anfangszustand einzurichten. Ein Destruktor ist das Spiegelbild: eine spezielle Funktion, die läuft, wenn ein Objekt stirbt, um danach aufzuräumen.

Du deklarierst ihn mit dem Klassennamen, dem eine Tilde (~) vorangestellt wird. Er nimmt keine Parameter, gibt nichts zurück, und eine Klasse kann genau einen davon haben. Du rufst ihn fast nie von Hand auf - C++ ruft ihn im richtigen Moment für dich auf.

#include <iostream>
using namespace std;

class Logger {
public:
    Logger()  { cout << "Logger created\n"; }   // Konstruktor
    ~Logger() { cout << "Logger destroyed\n"; }  // Destruktor
};

int main() {
    Logger log;                  // "Logger created"
    cout << "doing work...\n";
    return 0;
}                                // "Logger destroyed" läuft hier, automatisch

Beachte, dass die Destruktor-Meldung nachdem main den Funktionsrumpf beendet hat, aber bevor das Programm endet, ausgegeben wird. Wenn log an der schließenden geschweiften Klammer seinen Gültigkeitsbereich verlässt, führt C++ ~Logger() für dich aus.

Wann Destruktoren laufen

Der genaue Zeitpunkt hängt davon ab, wo das Objekt lebt:

• Stack-Objekte (lokale) werden zerstört, wenn sie ihren Gültigkeitsbereich verlassen - an der schließenden } des Blocks.
• Heap-Objekte (mit new erzeugt) werden zerstört, wenn du delete aufrufst. Vergisst du das delete, läuft der Destruktor nie und du verursachst ein Leck.

Dieses Beispiel macht den Unterschied sichtbar:

#include <iostream>
using namespace std;

class Tagged {
    int id;
public:
    Tagged(int i) : id(i) { cout << "create " << id << "\n"; }
    ~Tagged()             { cout << "destroy " << id << "\n"; }
};

int main() {
    Tagged a(1);              // create 1

    {
        Tagged b(2);          // create 2
    }                         // destroy 2  (b verlässt seinen inneren Gültigkeitsbereich)

    Tagged* c = new Tagged(3); // create 3
    delete c;                 // destroy 3  (das musst du selbst auslösen)

    return 0;
}                             // destroy 1  (a verlässt main)

Objekte werden in umgekehrter Reihenfolge ihrer Konstruktion zerstört. a wurde zuerst gebaut, also stirbt es zuletzt. Diese LIFO-Reihenfolge (last-in, first-out - zuletzt rein, zuerst raus) ist wichtig, wenn Objekte voneinander abhängen.

Warum Destruktoren wichtig sind: RAII

Die wahre Stärke von Destruktoren liegt darin, dass sie das Aufräumen automatisch und ausnahmesicher machen. Statt daran zu denken, eine Ressource auf jedem Codepfad freizugeben, legst du die Freigabe in einen Destruktor und lässt die Sprache garantieren, dass er läuft. Dieses Muster heißt RAII - Resource Acquisition Is Initialization (Ressourcenbelegung ist Initialisierung) - und ist das Rückgrat von modernem C++.

Hier besitzt eine Klasse einen Heap-Puffer: Sie reserviert ihn im Konstruktor und gibt ihn im Destruktor frei, sodass Aufrufer new/delete nie selbst anfassen.

#include <iostream>
using namespace std;

class IntArray {
    int* data;
    int size;
public:
    IntArray(int n) : data(new int[n]), size(n) {
        for (int i = 0; i < size; ++i) data[i] = i * i;
        cout << "allocated " << size << " ints\n";
    }
    ~IntArray() {
        delete[] data;                 // passt zum new[] oben
        cout << "freed the buffer\n";
    }
    int at(int i) const { return data[i]; }
};

int main() {
    IntArray squares(5);
    cout << "squares[3] = " << squares.at(3) << "\n";  // 9
    return 0;
}   // ~IntArray() läuft hier: der Puffer wird freigegeben, selbst wenn wir es vergessen hätten

Die zentrale Erkenntnis: Selbst wenn nach der Erzeugung von squares eine Ausnahme geworfen würde, würde der Stack abgewickelt und ~IntArray() liefe trotzdem. Diese Garantie macht RAII so zuverlässig - und ist der Grund, warum du in gutem C++-Code selten ein nacktes delete schreibst.

Die Dreierregel (und die Fünferregel)

Eine Klasse mit eigenem Destruktor besitzt fast immer eine rohe Ressource, und das schafft eine versteckte Gefahr. Der vom Compiler erzeugte Kopierkonstruktor und die Kopierzuweisung machen eine flache Kopie - sie kopieren den Zeiger, nicht den Puffer, auf den er zeigt. Nun halten zwei Objekte denselben Zeiger, und beide Destruktoren werden ihn mit delete löschen, was einen Double-Free-Absturz verursacht.

IntArray a(5);
IntArray b = a;   // flache Kopie: a.data und b.data sind DERSELBE Zeiger
// am Ende des Gültigkeitsbereichs: der Destruktor von b gibt den Puffer frei,
// dann gibt der Destruktor von a ihn ERNEUT frei -> undefiniertes Verhalten (Double Free)

Das führt zur Dreierregel: Wenn du eines der drei - Destruktor, Kopierkonstruktor oder Kopierzuweisungsoperator - schreibst, brauchst du mit ziemlicher Sicherheit alle drei. In C++11 und später erweitert sie sich zur Fünferregel, die den Move-Konstruktor und die Move-Zuweisung hinzufügt.

Es gibt jedoch eine noch bessere Regel - die Nullerregel: Entwirf Klassen so, dass du gar keine rohen Ressourcen verwaltest. Halte stattdessen einen std::vector, einen std::string oder einen Smart Pointer, und der vom Compiler erzeugte Destruktor macht das Richtige umsonst.

#include <iostream>
#include <vector>
using namespace std;

class IntArray {
    vector<int> data;              // verwaltet seinen eigenen Speicher
public:
    IntArray(int n) : data(n) {
        for (int i = 0; i < n; ++i) data[i] = i * i;
    }
    int at(int i) const { return data[i]; }
    // Kein Destruktor, kein Kopier-/Move-Code nötig: vector erledigt alles.
};

int main() {
    IntArray a(5);
    IntArray b = a;                // sichere tiefe Kopie - vector kopiert sich selbst
    cout << b.at(3) << "\n";       // 9
    return 0;
}

Greife standardmäßig zur Nullerregel. Schreibe einen eigenen Destruktor nur, wenn du wirklich eine rohe Ressource besitzt, die kein Standardtyp für dich kapselt.

Virtuelle Destruktoren

Wenn du ein Objekt über einen Zeiger auf die Basisklasse löschst, muss der Destruktor virtual sein - sonst wird nur der Basisteil zerstört und der abgeleitete Teil leckt. Das ist einer der häufigsten Fehler in polymorphem Code, und der Compiler warnt dich standardmäßig nicht davor.

#include <iostream>
using namespace std;

struct Base {
    virtual ~Base() { cout << "~Base\n"; }   // virtual ist hier unverzichtbar
};

struct Derived : Base {
    ~Derived() { cout << "~Derived\n"; }
};

int main() {
    Base* p = new Derived();
    delete p;                  // ~Derived dann ~Base, beide laufen korrekt
    return 0;
}

Ohne virtual an ~Base würde delete p nur ~Base() aufrufen - undefiniertes Verhalten, und der Derived-Teil des Objekts wird nie aufgeräumt. Faustregel: Jede Klasse mit virtuellen Funktionen (eine polymorphe Basisklasse) braucht einen virtuellen Destruktor. Du wirst genau sehen, warum das wichtig ist, sobald du anfängst, Klassen abzuleiten.

Häufige Fehler und Fallstricke

Ein paar Fallen bringen fast jeden zu Fall:

Nicht zusammenpassende new/delete. Wenn du mit new[] reservierst, gib mit delete[] frei. new[] mit einem schlichten delete (oder umgekehrt) zu mischen, ist undefiniertes Verhalten.

virtual an einem Basis-Destruktor vergessen. Wie oben: Ein abgeleitetes Objekt über einen Basiszeiger ohne virtuellen Destruktor zu löschen, leckt den abgeleiteten Teil. Wenn du eine Klasse schreibst, von der geerbt werden soll, mach den Destruktor virtuell.

Ausnahmen aus einem Destruktor entkommen lassen. Ein Destruktor, der während der Stack-Abwicklung eine Ausnahme wirft, beendet dein Programm. In modernem C++ sind Destruktoren implizit noexcept - halte den Aufräumcode davon ab, Ausnahmen zu werfen, oder schlucke die Ausnahme innerhalb des Destruktors.

Einen Destruktor schreiben, den du nicht brauchst. Wenn deine Member sich bereits selbst aufräumen, fügt ein leerer ~Klassenname() {} nur Lärm hinzu und kann Move-Operationen stillschweigend deaktivieren. Wenn es nichts aufzuräumen gibt, schreibe gar keinen Destruktor.

Als Nächstes: Vererbung

Du hast nun den vollständigen Lebenszyklus eines Objekts gesehen - Konstruktoren erwecken es zum Leben, Destruktoren räumen es auf, und virtual-Destruktoren halten dieses Aufräumen korrekt, wenn eine Klasse auf einer anderen aufbaut. Dieser letzte Punkt ist eine Vorschau auf die nächste große Idee: Vererbung, bei der eine Klasse die Daten und das Verhalten einer anderen wiederverwendet und erweitert. Die nächste Seite zeigt, wie man eine Klasse von einer anderen ableitet, wie sich Konstruktion und Zerstörung durch die Hierarchie ketten, und wie die Teile, die du gerade gelernt hast, zusammenpassen.