Beschreiben Sie die Regel der drei und der fünf (Rule of Three / Rule of Five) in C++11 und deren Bedeutung beim Entwurf von Klassen.

Antwort.

Regel der drei: Wenn eine Klasse einen Ressourcen verwaltet (z. B. Speicher), müssen beim expliziten Implementieren einer der folgenden Methoden auch die anderen implementiert werden:

• Destruktor
• Kopierkonstruktor
• Kopierzuweisungsoperator

C++11: Regel der fünf – es wurden verschiebende Operationen hinzugefügt:

• Verschiebekonstruktor
• Verschiebezuweisungsoperator

Ein Verstoß gegen diese Regel führt zu Fehlern im Ressourcenmanagement, wie doppelte Löschung oder Speicherlecks.

Beispielcode:

class Buffer {
    char* data;
public:
    Buffer(size_t sz) : data(new char[sz]) {}
    ~Buffer() { delete[] data; }
    Buffer(const Buffer& other)
        : data(new char[strlen(other.data)+1]) { strcpy(data, other.data); }
    Buffer& operator=(const Buffer& other) {
        if (&other != this) {
            delete[] data;
            data = new char[strlen(other.data)+1];
            strcpy(data, other.data);
        }
        return *this;
    }
    // move-Semantik in C++11+:
    Buffer(Buffer&& other) noexcept : data(other.data) { other.data = nullptr; }
    Buffer& operator=(Buffer&& other) noexcept {
        if (&other != this) {
            delete[] data;
            data = other.data;
            other.data = nullptr;
        }
        return *this;
    }
};

Fangfrage.

Reicht es aus, nur den Destruktor zu implementieren, wenn die Klasse einen Zeiger verwaltet?

Nein. Ohne Kopier- und verschiebe Operationen wird bei einer Kopie eine doppelte Löschung des Speichers auftreten. Zum Beispiel:

Buffer a(10);
Buffer b = a; // b und a werden denselben Zeiger löschen!

Beispiele realer Fehler aufgrund mangelnden Wissens zu diesem Thema.

---

Geschichte

In der Datenaggregationsplattform für Telekommunikation hatten alle Klassen nur den Destruktor implementiert. Nach der Refaktorisierung der Struktur kam es zu massiven Abstürzen durch doppelte Freigabe: Das Kopieren von Objekten führte zu zufälligen Verhalten.

---

Geschichte

Im Projekt eines mobilen Spiels wurde vergessen, den Move-Konstruktor für die Containerklasse Buffer zu implementieren. Bei der Verschiebung wurde das Objekt kopiert, was zu überflüssigen Kopiervorgängen führte und die Leistung beeinträchtigte.

---

Geschichte

In der Bibliothek zur Serialisierung von Datenstrukturen wurde bei der Rückgabe eines Objekts aus einer Funktion ein temporäres Objekt zurückgegeben, und der Kopierkonstruktor führte eine flache Kopie des Zeigers durch. Es gab viele Speicherlecks, die sich erst Monate später zeigten.