spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das Betriebssystem macht das, aber man sollte trotzdem alles freigeben. Speziell System-Ressourcen werden nämlich eventuell nicht aufgeräumt.

Das ist unterschiedlich. Das können Sockets sein, Dateien, Texturen, Brushes, Device-Contexts, Timer, ...

Einfache Regel: Alles, was Du anforderst, musst Du auch wieder freigeben.

Man kann davon ausgehen, dass das Bertiebssystem den Speicher am Ende aufräumt. Ich verließe mich nicht darauf. Es ist einfach guter Stil, die Resourcen, die man anfordert, auch wieder frei zu geben. Im Fall von C++ gibt es genügend Hilfmittel, welche einem die "Merkliste" abnehmen (STL-Container, smart-pointer, ...). Notfalls schreibt man sich einen Wrapper, welcher bei Zerstörung aufräumt.

Selbst in Python (was derzeit meinen Fokus hat) sollte man trotz refcounting einige Dinge berücksichtigen (besonders files seien da erwähnt).

Grüße ... Heiko

PS. BlueCobold schreibt schon wieder schneller.

Bei modernen Betriebssystemen wird eigentlich schon alles freigegeben, auch Dateien, Events, ...
Aber solltest du mal für den Embedded-Bereich programmieren, dann kann man sich darauf nicht mehr unbedingt verlassen.

Generell sollte man sich darauf imo auf keinen Fall verlassen. Denn das verführt zu Code, der durchzogen ist von Memory-Leaks. Und gegen die kann das Betriebssystem leider nichts tun...

Es gibt auch viele Leute, die meine, in einem guten C++ Programm sollte so gut wie keine delete auftauchen:


Der Destruktor des Filestreams schließt die Datei automatisch, sobald sie nicht mehr benutzt wird (der Scope (also doStuff()) verlassen wird). Ein fclose kann man vergessen, einen Destruktoraufruf nicht. Natürlich kann man jetzt sagen, ein expliziter File.close()
Aufruf wäre schöner, und er würde auch funktionieren und das erwartete tun, aber ratsam ist er trotzdem nicht: Es wäre möglich, dass am Ende nocheinmal etwas mit der Datei gemacht werden soll. Vielleicht hat man die Aufruf vergessen und versuch jetzt in eine geshclossene Datei zu schreiben. Viel schöner ist es, Objekte möglichst lokal zu halten, in etwa so:

Die Datei wird so direkt nach dem Schreiben geschlossen und wenn man später versucht, auf das Objekt zuzugreifen, merkt das schon der Compiler - und Compilerfehler sind IMMER(!!) besser als Laufzeitfehler. Und dadurch, dass die Datei bereits im Konstruktor geöffnet wird, ist sie über ihren gesamten Lebenszeitraum hinweg gültig, was ein sehr großer Vorteil ist. Siehe dazu auch:

http://en.wikipedia.org/wiki/Resource_Ac…_Initialization
(oder die kurze, aber duetsche Version: http://de.wikipedia.org/wiki/Ressourcenb…Initialisierung)

Das selbe funktioniert so ziemlich mit allen Ressourcen in C++. Statt Arrays gibt es std::vector, oder eben ein anderer Container, je nach Anwendung. Für einzelne Objekte am Heap gibt es eine ganze Reihe verschiedener Smartpointer, zum Beispiel von boost oder im neuen C++ Standard (und davor in std::tr1, meine ich).

Also: Lass den Compiler deine Ressourcen verwalten (und überlege immer, ob du nicht ein close oder delete vermeiden kannst, durch Einsatz anderer Klassen). Es ist gut und wichtig, zu wissen was im Hintergrund geschieht, aber man sollte ruhig auf einer höheren Ebene Programmieren.

Zitat von »Jonathan_Klein«

Es gibt auch viele Leute, die meine, in einem guten C++ Programm sollte so gut wie keine delete auftauchen:

	C-/C++-Quelltext
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	//C void doStuff() { FILE *File=NULL; File=fopen("bla"); ///Datei operationen: fclose(File); //other Stuff } //C++ void doStuff() { fstream File("bla"); File<< Data; //kein File.close() //other Stuff }

(...)

Das ist ein schönes Beispiel wie man einen automatischen Destruktoraufruf beim Verlassen einer Funktion zu was benutzen kann. Aber nach Möglichkeit ohne delete auskommen? Man kann probieren es zu minimieren, aber abgesehen von sehr einfachen Programmen wird man oft ohne dynamisch zur Laufzeit allokierten Speicher wohl kaum auskommen!

Natürlich braucht man den, aber man soll ihn mit Smartpointern benutzen.

Also ein einfacher scoped_ptr ist wohl immer besser, als ein nackter Zeiger (wenn er sich anwenden lässt), aber schon bei shared_ptr's wird die Sache etwas komplizierter und man muss zum Beispiel aufpassen, dass keine Ringe entstehen und so. Da bevorzuge ich es schon des öfteren, mich selbst um alles zu kümmern.

Komplexe Abhängigkeiten zwischen Objekten sind eh eine eklige Sache, für die es wohl keine automatische Lösung gibt. shared_ptr sind schon ganz ok, aber auch die ansich noch mächtigeren Garbage Collectors (bei denen das Ring Problem nicht mehr entsteht) sind kein Allheilmittel. Ich kann mich da an ein Java RTS erinnern, wo zerstörte Gebäude weiterlebten, weil ein Arbeiter noch eine Referenz darauf hatte. Aber wurden nicht mehr auf der Karte angezeigt und konnten nicht mehr angegriffen werden, aber dieser eine Arbeiter konnte dort trotzdem noch Ressourcen produzieren.