Geschichte: In C++98 folgte das Ressourcenmanagement der Regel von drei: Wenn eine Klasse einen benutzerdefinierten Destructor, Konstruktor oder Zuweisungsoperator benötigte, benötigte sie wahrscheinlich alle drei. Als C++11 die Move Semantics einführte, wurde dies zur Regel von fünf, was den Move-Konstruktor und den Move-Zuweisungsoperator hinzufügte. Das Standardkomitee wählte einen konservativen Ansatz: Die Deklaration eines Destructors (auch trivialer) behindert die implizite Generierung von Move-Operationen, um versehentliche flache Moves von Ressourcen zu verhindern, die von Destructors verwaltet werden.
Problem: Wenn Sie ~MyClass() = default; innerhalb der Klassendefinition schreiben, erstellen Sie einen "benutzerdeklarierten" Destructor. Gemäß dem C++-Standard ([class.copy.ctor]/3) unterdrückt diese Präsenz die implizite Deklaration sowohl des Move-Konstruktors als auch des Move-Zuweisungsoperators. Folglich behandelt der Compiler die Klasse als nur kopierbar und fällt stillschweigend auf teure Kopiersemantiken bei std::vector-Reallokationen oder Rückgaben durch Wert um, obwohl der Destructor keine tatsächliche Arbeit verrichtet.
Lösung: Um die implizite Move-Generierung aufrecht zu erhalten, deklarieren Sie den Destructor nur innerhalb der Klasse und geben Sie die standardisierte Definition außerhalb an:
class Optimized { public: ~Optimized(); // Nur hier deklariert std::array<char, 4096> buffer; }; Optimized::~Optimized() = default; // Außen definiert
Dies macht den Destructor "benutzerbereit", aber nicht "benutzerdeklariert" an dem Punkt, an dem der Compiler entscheidet, Moves zu generieren. Alternativ können Sie alle fünf speziellen Mitglieder explizit standardisieren oder vorzugsweise der Regel von Null folgen, indem Sie rohe Ressourcen durch std::unique_ptr oder Container ersetzen.
Wir hatten dies in einer Hochfrequenzhandel-Engine, die MarketDataPacket-Objekte bearbeitete. Die Klasse hielt einen festen 4KB-Puffer für Netzwerkdaten:
class MarketDataPacket { public: ~MarketDataPacket() = default; // Für "Klarheit" im Header geschrieben char buffer[4096]; };
Nach der Migration zu C++11 ergab die Latenzprofilmessung, dass 40% der CPU-Zyklen in memcpy verbracht wurden, obwohl die Pakete durch Wert zurückgegeben wurden. Der Übeltäter war der im Klasseninneren standardisierte Destructor, der versehentlich implizite Moves löschte und Kopien während des Wachstums von std::vector und Rückgaben von Funktionen zwang.
Lösung 1: Deklarieren Sie den noexcept Move-Konstruktor und die Zuweisung ausdrücklich. Dies behebt sofort das Leistungsproblem, indem Moves ermöglicht werden. Es erfordert jedoch die manuelle Wartung dieser Funktionen beim Hinzufügen von Mitgliedern, birgt Risiken hinsichtlich der Ausnahme-Spezifikationsübereinstimmung, wenn rohe Zeiger beteiligt sind, und fügt Boilerplate hinzu, die die Regel von Null verletzt.
Lösung 2: Verschieben Sie die Destructor-Definition in die .cpp-Datei mit MarketDataPacket::~MarketDataPacket() = default;. Dies stellt die vom Compiler generierten Moves wieder her, während der Destructor trivial bleibt. Es hält die Null-Overhead-Abstraktion aufrecht und ermöglicht Compiler-Optimierungen wie das Auslassen von Destruktoraufrufen für ungenutzte Objekte. Der einzige Nachteil besteht darin, dass eine separate Kompilationseinheit erforderlich ist, was akzeptabel war.
Lösung 3: Ersetzen Sie den rohen Puffer durch std::vector<uint8_t> oder std::unique_ptrstd::byte[]. Dies führt zu perfekter Einhaltung der Regel von Null. Allerdings führt dies zu Indirektion oder Heap-Zuweisungsoverhead, was in mikrosekundenempfindlichen Handelsstraßen, in denen die Cache-Lokalität kritisch ist, inakzeptabel ist.
Wir wählten Lösung 2. Durch das Verschieben der Standardisierung außerhalb der Klasse stellten wir die impliziten Moves wieder her, reduzierten die Paketverarbeitungslatenz von 12μs auf 3μs und hielten eine triviale Zerstörbarkeit aufrecht, die aggressive Compiler-Optimierungen ermöglichte.
Warum unterscheidet der Compiler zwischen der Standardisierung innerhalb der Klasse und außerhalb, wenn die Semantik identisch ist?
Der Unterschied ist syntaktisch, nicht semantisch. C++ verwendet ein Ein-Pass-Parsing-Modell für Klassendefinitionen. Wenn der Compiler die schließende Klammer der Klasse erreicht, muss er entscheiden, ob er implizite Move-Operationen generieren soll. Wenn er = default innerhalb sieht, ist der Destructor an diesem Punkt "benutzerdeklariert", was die Unterdrückungsregeln gemäß [class.copy]/7 auslöst. Der Compiler kann nicht "vorhersehen", um diese Entscheidung zu ändern, basierend auf der externen Definition. Dies ist eine grundlegende Einschränkung des Kompilationsmodells von C++.
Stellt die Markierung des Destructors als noexcept die impliziten Moves wieder her?
Nein. Die Unterdrückung der impliziten Move-Generierung hängt nur davon ab, ob der Destructor benutzerdeklariert ist, nicht von seiner Ausnahme-Spezifikation. Während es wichtig ist, Moves als noexcept zu kennzeichnen, damit sie bei std::vector-Reallokationen verwendet werden, bringt das bloße Hinzufügen von noexcept zu einem standardisierten Destructor innerhalb der Klasse die gelöschten Move-Operationen nicht zurück. Sie müssen die Definition entweder nach außen verschieben oder die Moves ausdrücklich standardisieren.
Wie beeinflusst ein benutzerdeklarierter Destructor die Aggregatinitialisierung?
Eine Klasse mit einem benutzerdeklarierten Destructor hört auf, eine Aggregat zu sein. Dies ist oft disruptiver als der Verlust von Moves. Es bedeutet den Verlust von benannten Initialisierern (C++20) und der Fähigkeit, geschweifte Initialisierungslisten ohne explizite Konstruktoren zu verwenden. Viele Entwickler erwarten, dass die Aggregatinitialisierung funktioniert, und sind überrascht, wenn sie fehlschlägt:
struct Config { ~Config() = default; // Bricht die Aggregation int value; }; // Config c{42}; // Fehler: kein passender Konstruktor
Das passiert, weil die Präsenz eines benutzerdeklarierten Destructors die Klasse zwang, nicht-triviale Zerstörungssemantiken im Typsystem zu haben, und sie aus dem Aggregatstatus ausschließt, unabhängig von der tatsächlichen Komplexität.