Destruktory w C++: ~ClassName, RAII i sprzątanie

Czym jest destruktor

Na poprzedniej stronie pojawiły się konstruktory: specjalne funkcje, które uruchamiają się, gdy obiekt się rodzi, i ustawiają jego stan początkowy. Destruktor to lustrzane odbicie: specjalna funkcja, która uruchamia się, gdy obiekt umiera, aby po nim posprzątać.

Deklarujesz go jako nazwę klasy poprzedzoną tyldą (~). Nie przyjmuje parametrów, nic nie zwraca, a klasa może mieć dokładnie jeden. Prawie nigdy nie wywołujesz go ręcznie: C++ robi to za ciebie we właściwym momencie.

#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" uruchamia się tutaj, automatycznie

Zwróć uwagę, że komunikat destruktora pojawia się po zakończeniu ciała main, ale przed wyjściem z programu. Gdy log wychodzi z zasięgu przy zamykającej klamrze, C++ uruchamia za ciebie ~Logger().

Kiedy działają destruktory

Dokładny moment zależy od tego, gdzie żyje obiekt:

• Obiekty na stosie (lokalne) są niszczone, gdy wychodzą z zasięgu, przy zamykającym } bloku.
• Obiekty na stercie (utworzone przez new) są niszczone, gdy wywołujesz delete. Jeśli zapomnisz o delete, destruktor nigdy się nie uruchomi i powstanie wyciek.

Ten przykład pokazuje różnicę:

#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 opuszcza swój wewnętrzny zasięg)

    Tagged* c = new Tagged(3); // create 3
    delete c;                 // destroy 3  (musisz to wywołać samodzielnie)

    return 0;
}                             // destroy 1  (a opuszcza main)

Obiekty są niszczone w odwrotnej kolejności do konstrukcji. a powstał pierwszy, więc ginie ostatni. Ta kolejność LIFO (ostatni na wejściu, pierwszy na wyjściu) ma znaczenie, gdy obiekty od siebie zależą.

Dlaczego destruktory są ważne: RAII

Prawdziwa siła destruktorów polega na tym, że sprzątanie staje się automatyczne i bezpieczne wobec wyjątków. Zamiast pamiętać o zwolnieniu zasobu na każdej ścieżce kodu, umieszczasz zwolnienie w destruktorze, a język gwarantuje, że ono nastąpi. Ten wzorzec nazywa się RAII (Resource Acquisition Is Initialization) i stanowi kręgosłup współczesnego C++.

Tutaj klasa posiada bufor na stercie: alokuje go w konstruktorze i zwalnia w destruktorze, więc wywołujący nigdy sami nie dotykają new/delete.

#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;                 // para dla new[] powyżej
        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;
}   // tu uruchamia się ~IntArray(): bufor zostaje zwolniony, nawet jeśli o tym zapomnimy

Kluczowa obserwacja: nawet gdyby po utworzeniu squares został rzucony wyjątek, stos by się zwinął, a ~IntArray() i tak by się uruchomił. Ta gwarancja sprawia, że RAII jest tak niezawodne, i dlatego w dobrym kodzie C++ rzadko pisze się gołe delete.

Reguła trzech (i pięciu)

Klasa z własnym destruktorem prawie zawsze posiada surowy zasób, a to tworzy ukryte niebezpieczeństwo. Konstruktor kopiujący i przypisanie kopiujące wygenerowane przez kompilator wykonują kopię płytką: kopiują wskaźnik, a nie bufor, na który on wskazuje. Teraz dwa obiekty trzymają ten sam wskaźnik i oba destruktory wywołają na nim delete, co kończy się awarią podwójnego zwolnienia.

IntArray a(5);
IntArray b = a;   // płytka kopia: a.data i b.data to TEN SAM wskaźnik
// na końcu zasięgu: destruktor b zwalnia bufor,
// potem destruktor a zwalnia go PONOWNIE -> niezdefiniowane zachowanie (double free)

Stąd reguła trzech: jeśli piszesz którykolwiek z elementów: destruktor, konstruktor kopiujący albo operator przypisania kopiującego, niemal na pewno potrzebujesz wszystkich trzech. Od C++11 rozszerza się to do reguły pięciu, która dodaje konstruktor przenoszący i przypisanie przenoszące.

Jest jednak jeszcze lepsza zasada, reguła zera: projektuj klasy tak, aby w ogóle nie zarządzały surowymi zasobami. Trzymaj zamiast tego std::vector, std::string albo inteligentny wskaźnik, a destruktor wygenerowany przez kompilator za darmo zrobi, co trzeba.

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

class IntArray {
    vector<int> data;              // sam zarządza swoją pamięcią
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]; }
    // Nie trzeba destruktora ani kodu kopiowania/przenoszenia: vector załatwia to wszystko.
};

int main() {
    IntArray a(5);
    IntArray b = a;                // bezpieczna głęboka kopia: vector kopiuje się sam
    cout << b.at(3) << "\n";       // 9
    return 0;
}

Domyślnie sięgaj po regułę zera. Własny destruktor pisz tylko wtedy, gdy naprawdę posiadasz surowy zasób, którego nie opakowuje za ciebie żaden typ standardowy.

Destruktory wirtualne

Gdy usuwasz obiekt przez wskaźnik na klasę bazową, destruktor musi być virtual. W przeciwnym razie zniszczona zostanie tylko część bazowa, a część pochodna wycieknie. To jeden z najczęstszych błędów w kodzie polimorficznym, a kompilator domyślnie nie ostrzega o nim.

#include <iostream>
using namespace std;

struct Base {
    virtual ~Base() { cout << "~Base\n"; }   // virtual jest tu niezbędne
};

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

int main() {
    Base* p = new Derived();
    delete p;                  // ~Derived, potem ~Base, oba działają poprawnie
    return 0;
}

Bez virtual przy ~Base wywołanie delete p uruchomiłoby tylko ~Base(): to niezdefiniowane zachowanie, a część Derived obiektu nigdy nie zostałaby posprzątana. Praktyczna zasada: każda klasa z funkcjami wirtualnymi (polimorficzna klasa bazowa) potrzebuje wirtualnego destruktora. Dokładnie zobaczysz, dlaczego to ważne, gdy zaczniesz tworzyć klasy pochodne.

Częste błędy i pułapki

Kilka pułapek łapie prawie każdego:

Niedopasowane new/delete. Jeśli alokujesz przez new[], zwalniaj przez delete[]. Mieszanie new[] ze zwykłym delete (lub odwrotnie) to niezdefiniowane zachowanie.

Brak virtual przy destruktorze bazowym. Jak wyżej: usunięcie obiektu pochodnego przez wskaźnik bazowy bez wirtualnego destruktora powoduje wyciek części pochodnej. Jeśli piszesz klasę przeznaczoną do dziedziczenia, zrób destruktor wirtualnym.

Wypuszczanie wyjątków z destruktora. Destruktor, który rzuca wyjątek podczas zwijania stosu, kończy działanie programu. We współczesnym C++ destruktory są niejawnie noexcept: pilnuj, aby kod sprzątający nie rzucał wyjątków, albo przechwytuj je wewnątrz destruktora.

Pisanie niepotrzebnego destruktora. Jeśli pola same po sobie sprzątają, puste ~ClassName() {} dodaje tylko szumu i może po cichu wyłączyć operacje przenoszenia. Gdy nie ma czego sprzątać, nie pisz destruktora wcale.

Dalej: dziedziczenie

Znasz już pełny cykl życia obiektu: konstruktory powołują go do życia, destruktory po nim sprzątają, a destruktory virtual dbają o poprawność tego sprzątania, gdy jedna klasa buduje na drugiej. Ten ostatni punkt to zapowiedź kolejnej dużej idei: dziedziczenia, w którym klasa ponownie wykorzystuje i rozszerza dane i zachowanie innej. Następna strona pokazuje, jak wyprowadzić jedną klasę z drugiej, jak konstrukcja i destrukcja przechodzą przez hierarchię i jak łączą się elementy, które właśnie poznajesz.