Verwenden Sie RAII
- Vergessen Sie die Garbage Collection (verwenden Sie stattdessen RAII). Beachten Sie, dass auch der Garbage Collector auslaufen kann (wenn Sie vergessen, einige Referenzen in Java / C # auf "null" zu setzen), und dass Garbage Collector Ihnen nicht dabei hilft, Ressourcen zu entsorgen (wenn Sie ein Objekt haben, für das ein Handle erworben wurde Bei einer Datei wird die Datei nicht automatisch freigegeben, wenn das Objekt den Gültigkeitsbereich verlässt, wenn Sie dies nicht manuell in Java tun oder das Muster "dispose" in C # verwenden.
- Vergessen Sie die Regel "eine Rückgabe pro Funktion" . Dies ist ein guter C-Rat, um Lecks zu vermeiden. In C ++ ist er jedoch aufgrund der Verwendung von Ausnahmen veraltet (verwenden Sie stattdessen RAII).
- Und während das "Sandwich-Muster" ein guter C-Rat ist, ist es in C ++ aufgrund der Verwendung von Ausnahmen veraltet (verwenden Sie stattdessen RAII).
Dieser Beitrag scheint sich zu wiederholen, aber in C ++ ist RAII das grundlegendste Muster, das man kennen muss .
Erfahren Sie, wie Sie intelligente Zeiger verwenden, sowohl von Boost über TR1 als auch von Auto_ptr (aber häufig effizient genug) (aber Sie müssen die Einschränkungen kennen).
RAII ist die Grundlage sowohl für die Ausnahmesicherheit als auch für die Ressourcenentsorgung in C ++, und kein anderes Muster (Sandwich usw.) gibt Ihnen beides (und meistens gibt es Ihnen keines).
Unten sehen Sie einen Vergleich von RAII- und Nicht-RAII-Code:
void doSandwich()
{
T * p = new T() ;
// do something with p
delete p ; // leak if the p processing throws or return
}
void doRAIIDynamic()
{
std::auto_ptr<T> p(new T()) ; // you can use other smart pointers, too
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}
void doRAIIStatic()
{
T p ;
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}
Zusammenfassend (nach dem Kommentar von Ogre Psalm33 ) stützt sich RAII auf drei Konzepte:
- Sobald das Objekt erstellt ist, funktioniert es einfach! Erwerben Sie Ressourcen im Konstruktor.
- Objektzerstörung ist genug! Machen Sie freie Ressourcen im Destruktor.
- Alles dreht sich um Bereiche! Objekte mit Gültigkeitsbereich (siehe doRAIIStatic-Beispiel oben) werden bei ihrer Deklaration erstellt und in dem Moment zerstört, in dem die Ausführung den Gültigkeitsbereich verlässt, unabhängig davon, wie der Exit (Rückgabe, Unterbrechung, Ausnahme usw.) erfolgt.
Dies bedeutet, dass im richtigen C ++ - Code die meisten Objekte nicht mit erstellt newwerden und stattdessen auf dem Stapel deklariert werden. Und für diejenigen, die mit konstruiert wurden new, sind alle irgendwie begrenzt (z. B. an einen intelligenten Zeiger angehängt).
Als Entwickler ist dies in der Tat sehr leistungsfähig, da Sie sich nicht um die manuelle Handhabung von Ressourcen kümmern müssen (wie in C oder für einige Objekte in Java, die try/ finallyfür diesen Fall intensiv nutzen ) ...
Bearbeiten (2012-02-12)
"Objekte mit Gültigkeitsbereich ... werden zerstört ... unabhängig vom Ausgang", das ist nicht ganz richtig. Es gibt Möglichkeiten, RAII zu betrügen. Jede Variante von terminate () umgeht die Bereinigung. exit (EXIT_SUCCESS) ist in dieser Hinsicht ein Oxymoron.
- wilhelmtell
wilhelmtell hat damit recht: Es gibt außergewöhnliche Möglichkeiten, RAII zu betrügen, die alle dazu führen, dass der Prozess abrupt gestoppt wird.
Dies sind außergewöhnliche Möglichkeiten, da C ++ - Code nicht mit Beenden, Beenden usw. übersät ist. Im Falle von Ausnahmen möchten wir, dass eine nicht behandelte Ausnahme den Prozess zum Absturz bringt und das Speicherabbild unverändert und nicht nach der Bereinigung ausgibt .
Aber wir müssen immer noch über diese Fälle Bescheid wissen, denn obwohl sie selten auftreten, können sie dennoch auftreten.
(Wer ruft an terminateoder exitin gelegentlichem C ++ - Code? ... Ich erinnere mich, dass ich mich beim Spielen mit GLUT mit diesem Problem befassen musste : Diese Bibliothek ist sehr C-orientiert und geht so weit, sie aktiv zu entwerfen, um es C ++ - Entwicklern zu erschweren, sich nicht darum zu kümmern über vom Stapel zugewiesene Daten oder über "interessante" Entscheidungen, niemals von ihrer Hauptschleife zurückzukehren ... dazu werde ich nichts sagen) .