Rainer Grimm hat am 1. September 2017 die Destruktor-Regeln der C++ Core Guidelines erläutert. Sein Beitrag behandelt Besitzverhältnisse, Vererbung und Fehler beim Aufräumen von Ressourcen. Die Empfehlungen betreffen auch Engine-Code und Entwicklungswerkzeuge, die Dateien, Speicher oder Systemressourcen verwalten.
Die C++ Core Guidelines empfehlen zunächst die Regel von null: Verwalten die Member ihre Ressourcen bereits selbst, ist häufig keine eigene Aufräumfunktion nötig. Ein eigener Destruktor ist sinnvoll, wenn am Ende der Objektlebensdauer eine zusätzliche Aktion erforderlich ist.
Kopieroperationen und Freigabe über Basisklassen
Wer eine Spezialfunktion selbst definiert oder mit =delete unterbindet, soll laut Regel C.21 auch die übrigen Spezialfunktionen ausdrücklich behandeln. Eine Klasse mit eigenem Freigabecode und ungeprüfter Standardkopie kann dieselbe Ressource zweimal freigeben. =default und =delete sind mögliche Entscheidungen; nicht jede Funktion braucht eine handgeschriebene Implementierung.
Für Basisklassen empfiehlt Regel C.35 einen öffentlichen virtuellen oder geschützten nichtvirtuellen Destruktor. Wird ein abgeleitetes Objekt über einen Basisklassenzeiger gelöscht, dessen Destruktor nicht virtuell ist, entsteht undefiniertes Verhalten. Das Problem ist nicht auf ein Speicherleck begrenzt.
noexcept verhindert keine Fehler im Funktionskörper
Die Regeln C.36 und C.37 verlangen Destruktoren ohne nach außen geworfene Ausnahme. Verlässt eine Ausnahme einen noexcept-Destruktor, wird std::terminate aufgerufen. Die Deklaration repariert also keine fehlerhafte Aufräumlogik.
Archivhinweis: Verlinkt ist die offizielle Guideline-Fassung vom August 2017. Der Beitrag beschreibt damalige Empfehlungen, keine neue C++-Sprachversion.