spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das ist so als würdest du ein Handtuch auf ne Liege am Pool legen und vergessen wo die Liege ist. Dann kann sich den ganzen Tag keiner mehr auf die Liege legen. Wenn du das sehr oft an einem Tag machst gibt es immer weniger freie Liegen.

http://de.wikipedia.org/wiki/Speicherleck
Da findest du noch etwas mehr dazu.

Zitat von »NachoMan«

Das ist so als würdest du ein Handtuch auf ne Liege am Pool legen und vergessen wo die Liege ist. Dann kann sich den ganzen Tag keiner mehr auf die Liege legen. Wenn du das sehr oft an einem Tag machst gibt es immer weniger freie Liegen.

Sehr gute Erklärung ! Und um das zu verhindern gibt es einen ganz besonderen Typ von Urlauber: der Müllsammler. er geht herrum und sammelt solche handtücher auf und wirft sie in den Pool.
Hoffentlich weiß er auch, welche Handtücher wirklich nicht mehr benutzt werden

Zitat von »idontknow«

	C-/C++-Quelltext
1 2 3	int* intPointer = new int; intPointer = 0; // -> kein Zugriff mehr auf den Speicher auf den intPointer zuvor gezeigt hat, aber der Speicher ist immernoch da nur noch reserviert, kann also trotzdem nicht mehr genutzt werden!

kann man sich nicht einfach das

sparen?

Wenn mein Programm eine Exception wirft, bevor ich delete gesagt habe, dann sollte ich den selben Effekt erzielen.

Am besten kein new Operator benutzen und wenn doch dann auto_ptr* nutzen oder eine Wrapperklasse drum bauen.


*auto_ptr geht nicht mit vector!

Du verstehst da etwas falsch. Das Beispiel soll ein Speicherleck heraufbeschwören. Es wird mit new Speicher für ien int geholt. Dann wird die Adresse von intPointer einfach auf 0 gesetzt. Das bedeutet es zeigt keine Variable mehr auf den vorher geholten Speicher. Der Speicher ist also reserviert aber kann nicht mehr freigegeben werden. Natürlich gibt es noch andere Wege dahin zu kommen Wenn dein Programm eine Exception wirft und du den Speicher dann nicht freigibst, dann kommt es so natürlich auch zum Speicherleck. Klar kann man sowas verhindern indem man smart pointer benutzt. Dafür gibt es die ja.

Wobei auch der Smartpointer eine Schwäche hat: Objekte die sich gegenseitig referenzieren halten sich immer im Speicher, auch wenn man nicht mehr wirklich dran kann. Aber solange man darauf achtet, dass sich keine Objekte per Smartpointer gegenseitig referenzieren, ist der Smartpointer schon gut.

Zuersteinmal hängt es von der Art von Smartpointer ab, ob so eine Konstellation überhaupt zustandekommen kann. Mit einem unique_ptr ist es z.B. schon rein aus Prinzip unmöglich sowas zu basteln. Und wenn man, z.B. mit einem shared_ptr, tatsächlich so eine Konstellation geschaffen hat, dann hat man sehr wahrscheinlich irgendwo einen grundlegenden Fehler im Design. Denn normalerweise sollte wohl eines der beiden Objekte höchstens eine Weak-Reference haben und keinen Smartpointer.

Meiner Erfahrung nach braucht man shared Ownership aber überhaut nur äußerst selten. Ich persönlich sehe shared Ownership jedenfalls als mögliches Symptom eines nicht ganz durchdachten Designs, denn imo zeigt ein shared_ptr mir an, dass der Scope der betroffenen Objekte irgendwie nicht so ganz klar ist.