Speicherverwaltung Begriffsdefinition

HansGerber · 25. April 2010, 17:12

dass man setXYZ:[[MyObject alloc] init] nicht machen darf ist ja wohl klar. das hat aber nix mit dem setter zu tun.

Dann muss ich mich als Unbedarfter langsam fragen, warum 2 Informatik-Absolventen, die Seminare zu Compilerkonstruktion und Objective-C geben, in ihrem Buch so einen Konstrukt verwenden ?

Hans

Michael · 25. April 2010, 17:36

HansGerber schrieb:

dass man setXYZ:[[MyObject alloc] init] nicht machen darf ist ja wohl klar. das hat aber nix mit dem setter zu tun.

Dann muss ich mich als Unbedarfter langsam fragen, warum 2 Informatik-Absolventen, die Seminare zu Compilerkonstruktion und Objective-C geben, in ihrem Buch so einen Konstrukt verwenden ?

Entweder haben die beiden die Speicherverwaltung von Objective-C/Cocoa nicht kapiert oder sie arbeiten grundsätzlich mit der Garbage Collection.

Michael

Lucas de Vil · 25. April 2010, 18:04

Gritsch schrieb:

dass man setXYZ:[[MyObject alloc] init] nicht machen darf ist ja wohl klar.

Offenbar nicht, nech?

HansGerber schrieb:

Dann muss ich mich als Unbedarfter langsam fragen, warum 2 Informatik-Absolventen, die Seminare zu Compilerkonstruktion und Objective-C geben, in ihrem Buch so einen Konstrukt verwenden?

Ich behaupte jetzt einfach mal, du hast es nicht korrekt gelesen.
Entweder ist dir im Vorfeld die Aktivierung der GarbageCollection entgangen oder auf den fortfolgenden Seiten wird erklärt, warum das so nicht funktionieren kann.

HansGerber schrieb:

Nach [object release], wenn also rc = 0 wird, wird doch dealloc aufgerufen.
Wenn in diesem dealloc object.field1(2) = nil gesetzt wird, setzt dann nicht der Setter den rc durch Freigabe auf 0??

Du bringst die Zeiger und die Objekte im reservierten Speicherplatz durcheinander. Deshalb habe ich in meinem Code die Objekte mit x, y und z bezeichnet.

Ganz abstrakt passiert Folgendes im Code:

Quellcode

x anlegen und RC um 1 erhöhen
y als Property 1 von x anlegen und RC um 2 erhöhen (+alloc und das -retain im Setter)
z als Property 2 von x anlegen und RC um 2erhöhen (+alloc und das -retain im Setter)
z als Property 1 von x übernehmen und RC auf 3 erhöhen (-retain im Setter)
dadurch y einmal freigaben, da Verweis darauf weg (RC 1 wegen Release im Setter)
x freigeben (RC 0)
dadurch z zwei mal freigeben (RC 1 denn -release in beiden Settern), da Verweise darauf weg

Du kommst weder an Objekt y noch an Objekt z ran, obwohl beide noch im Speicher liegen. Du hast einfach nichts mehr, was darauf zeigt. Dementsprechend kannst du die Objekte auch nicht mehr freigeben.
Da hilft dir auch kein Setzen auf nil irgendwo drin, da der Release Count das erste Mal bereits beim +alloc um eins erhöht wurde und du irgendwie dieses aufheben musst.
Ein -release direkt an das Objekt schicken kannst du aber nicht, weil du nicht mehr an das Objekt rankommst, da kein Zeiger darauf mehr existiert.

Amin Negm-Awad · 26. April 2010, 06:35

Lucas de Vil schrieb:

Amin Negm-Awad schrieb:

Nein, es wäre richtig, weil der Setter auch die alte Instanz wieder freigibt.

So wie ich das sehe ist es falsch und HansGerber hat mit seiner Vermutung recht.

Quellcode

MyObject* object = [[MyObject alloc] init] //x hat nen RC1 durchs alloc

[object setField1:[[MyObject alloc] init]] //y hat nen RC1 durchs alloc, RC2 durch den Retain-Setter

[object setField2:[[MyObject alloc] init]] //z hat nen RC1 durchs alloc, RC2 durch den Retain-Setter

[object setField1:[object field2]] //x RC1, y RC1 durchs Release im Setter, z RC3 durch den zweiten Setter

[object release]; // x RC0 durchs Release, y bleibt bei RC1, z RC1 durchs Release von field1 und field2

[…]

Ich habe zu dem ursprünglichen Verweis geschrieben. Um den hat sich der Setter zu kümmern und sonst niemand. Dass das insgesamt ein Memory-Leak ist, habe ich schon in dem vorangegangenem Thread geschrieben (Den Code sehen wir jetzt im dritten Thread von Hans.)

Amin Negm-Awad · 26. April 2010, 06:38

HansGerber schrieb:

So wie ich das sehe ist es falsch und HansGerber hat mit seiner Vermutung recht.

Gute Güte, wenn sich schon die Experten uneins sind, wie soll ich da je auf einen grünen Zweig kommen, äh, das ganze kapieren.
Andererseits beruhigt es irgendwie, bin ich doch nicht alleine ....
[…]

Nein, Lucas und ich sprachen von verschiedenen Problemen. Du hast einmal die Erzeugung, die du balancieren musst. Davon sprach Lucas.
Dann hast du den Verweis der irgendwann einmal von Setter vorgenommen wird und der irgendwann einmal wieder im Setter ungültig wird. Hiervon sprach ich.

In beiden Fällen benötigst du einen -release.

Amin Negm-Awad · 26. April 2010, 06:39

HansGerber schrieb:

dass man setXYZ:[[MyObject alloc] init] nicht machen darf ist ja wohl klar. das hat aber nix mit dem setter zu tun.

Dann muss ich mich als Unbedarfter langsam fragen, warum 2 Informatik-Absolventen, die Seminare zu Compilerkonstruktion und Objective-C geben, in ihrem Buch so einen Konstrukt verwenden ?

Hans

Ich habe das Buch nicht gelesen, aber gehört, dass in dem Buch haufenweise Blödsinn steht.

Amin Negm-Awad · 26. April 2010, 06:41

gritsch schrieb:

leute was macht ihr hier fürn radau?

dass man setXYZ:[[MyObject alloc] init] nicht machen darf ist ja wohl klar. das hat aber nix mit dem setter zu tun.

Na, ja, es ginge schon:

Quellcode

[instance setXYZ:[[MyClass alloc] init]];
[[instanace xYZ] release];

Wäre richtig, jedoch ziemlich absurd.

HansGerber · 26. April 2010, 07:31

Erstmal vielen Dank an alle für die Geduld und die Zeit, die ihr Euch nehmt um mir (auch auf dumme Fragen) zu antworten.

Leider ging das mit dem Durcharbeiten des Memory-Managements anhand des Buches wohl ziemlich in die Hose und war eher kontraproduktiv. Scheinbar steht doch so mancher Unsinn drin, der mich ziemlich aus der Bahn wirft. Letzten Endes bringe ich wohl aber auch noch viele Dinge einfach durcheinander.
Nun denn, ich werde mir jetzt mal die Zeit nehmen und die ganzen Antworten in den beiden Speicher-Threads nochmals durchackern und versuchen zu verstehen und nachzuvollziehen, was Unsinn ist und war und wo und warum ein Speicherleck ist.
Sollte ich dann immer noch Fragen habe (wovon ich eigentlich fest ausgehe), werde ich nochmals nachhaken.
Das Thema Speicheverwaltung ist mir jetzt zu wichtig, um es einach beiseite zu legen.

Danke nochmals !
Hans

Amin Negm-Awad · 26. April 2010, 07:34

Jedenfalls hast du die richtige Einstellung. Weglegen kann man das Thema nicht.

HansGerber · 26. April 2010, 07:45

Achja, habe ich ganz vergessen.
Wen's interssiert. Das Kapitel Speicherverwaltung des besagten Buches liegt zufälligerweise als Leseprobe im Netz frei verfügbar vor :

mitp.de/imperia/md/content/vmi…26659669_leseprobe_02.pdf

Sollte der Inhalt dort richtig sein und ich es nur falsch verstanden und zitiert haben, soll es mir auch recht sein.
Schliesslich habe ich ja bezahlt für den Wälzer.

Hans

Michael · 26. April 2010, 07:51

Amin Negm-Awad schrieb:

Na, ja, es ginge schon:

Quellcode

[instance setXYZ:[[MyClass alloc] init]];

[[instanace xYZ] release];

Wäre richtig, jedoch ziemlich absurd.

Und wenn der Setter von xYZ kopiert, nützt selbst das nichts mehr.

Michael

Amin Negm-Awad · 26. April 2010, 07:56

Stimmt, bei einem Copy-Setter war es das. Man holt sich eben Vermutungen über Interna heraus.

Amin Negm-Awad · 26. April 2010, 08:00

HansGerber schrieb:

Achja, habe ich ganz vergessen.
Wen's interssiert. Das Kapitel Speicherverwaltung des besagten Buches liegt zufälligerweise als Leseprobe im Netz frei verfügbar vor :

mitp.de/imperia/md/content/vmi…26659669_leseprobe_02.pdf

Sollte der Inhalt dort richtig sein und ich es nur falsch verstanden und zitiert haben, soll es mir auch recht sein.
Schliesslich habe ich ja bezahlt für den Wälzer.

Hans

Ah, dann ist das doch ein anderes als von mir vermutet.

Es wird über sehen, dass der "Convenience-Constructor" selbst eine Abhängigkeit erzeugt. Keine Ahnung, ob das später richtig gestellt wird. Ich bin eindeutig zu faul, das durchzulesen.

macmoonshine · 26. April 2010, 08:07

HansGerber schrieb:

Achja, habe ich ganz vergessen.
Wen's interssiert. Das Kapitel Speicherverwaltung des besagten Buches liegt zufälligerweise als Leseprobe im Netz frei verfügbar vor :

mitp.de/imperia/md/content/vmi…26659669_leseprobe_02.pdf

Sollte der Inhalt dort richtig sein und ich es nur falsch verstanden und zitiert haben, soll es mir auch recht sein.
Schliesslich habe ich ja bezahlt für den Wälzer.

Hans

Schon beim flüchtigen durchschauen finden sich eine ganze Reihe Ungenautigkeiten. Dieses Buch provoziert zur Programmierung von Speicherlecks und ungenaue Formulierungen machen das Geschreibsel auch nicht verständlicher. Wenn es ein dickes Buch ist, hat es vielleicht wenigstens noch einen hohen Heizwert oder kann als Bildschirmständer dienen.

Kauf' Dir ein vernünftiges Buch. Die Speicherverwaltung ist so elementar. Wonach Du bei der Auswahl schauen solltest, solltest Du ja inzwischen wissen.

Amin Negm-Awad · 26. April 2010, 09:10

Wenn man so etwas liest:

NSString* string1 = [[[NSString alloc] initWithString: @"Hello"] retain];

fragt man sich schon, ob da jemand das Ding wirklich richtig vermittelt.

macmoonshine · 26. April 2010, 09:24

Im Text wird da zwar noch oberflächlich darauf eingegangen, aber dem Lesenden wird damit ein total falscher Eindruck vermittelt:

Das solche Anweisungen sinnvoll sein können.
Das der Retain-Count für ihn interessant ist.

Ein in diesem Zusammenhang so wichtiger und anschaulicher Begriff wie Eigentümerschaft fällt leider nicht. Hinterher ist vielleicht klar, wie es funktioniert aber nicht. wie es vernünftig angewendet wird. Der Anfänger sollte es aber genau umgekehrt lernen.

HansGerber · 26. April 2010, 09:40

Ich entnehme den Kommentaren dass ich für die 40,- Euro besser gut Essen gegangen wäre ...

macmoonshine · 26. April 2010, 09:50

Ja, das immer eine gute Idee. Aber tröste Dich. Ich habe mir auch schon eine ganze Reihe Schrottbücher zu allen möglichen Themen gekauft. Das lässt sich wahrscheinlich nie ganz vermeiden.

Wenn Du aber erkennst, warum ein Buch schlecht ist, dann hast Du jedenfalls schon eine Menge gelernt.

gritsch · 26. April 2010, 09:57

Amin Negm-Awad schrieb:

NSString* string1 = [[[NSString alloc] initWithString: @"Hello"] retain];

lol

Amin Negm-Awad · 26. April 2010, 10:12

macmoonshine schrieb:

Im Text wird da zwar noch oberflächlich darauf eingegangen, aber dem Lesenden wird damit ein total falscher Eindruck vermittelt:

Das solche Anweisungen sinnvoll sein können.
Das der Retain-Count für ihn interessant ist.

Ein in diesem Zusammenhang so wichtiger und anschaulicher Begriff wie Eigentümerschaft fällt leider nicht. Hinterher ist vielleicht klar, wie es funktioniert aber nicht. wie es vernünftig angewendet wird. Der Anfänger sollte es aber genau umgekehrt lernen.

Ja, deshalb schrieb ich schon ganz bewusst "vermittelt". Man ja manch schrägen RC wieder balancieren. Aber es geht eben bei RC nicht darum, einfach nur einen RC richtig hinzufrickeln, sondern darum dass man Eingentümerschaften hervorhebt. Das ist das Konzept, nicht irgendwo RC++ und RC--.

Die obige Zeile ist ganz gewiss kontrakonzeptionell, da eine doppelte Eigentümerschaft (1. +alloc, 2. -retain) aufgebaut wird, obwohl string1 ganz gewiss nicht doppelter Eigentümer ist (sein kann). Es ist daher einfach Ausdruck von "nicht verstanden, worum es geht". Finde ich im eigenen Code schon schlimm. Es zu vermitteln, ist eine Katastrophe. Das führt genau zu diesen "wilden" Retains und Releases, die hier in jedem zweiten Thread den Leuten ausgetrieben werden. Jetzt weiß ich wenigstens, unter welchem Stein die hervorgekrochen sind.