Speicherverwaltung Begriffsdefinition

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

HansGerber schrieb:

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

Na, es wird ja bestimmt auch Gutes in dem Buch geben. Die Speicherverwaltung gehört eben nur nicht dazu.

Aber lecker essen ist ja nie verkehrt.

macmoonshine · 26. April 2010, 10:18

Amin Negm-Awad schrieb:

Jetzt weiß ich wenigstens, unter welchem Stein die hervorgekrochen sind.

Ich aber fürchte, dass es da noch einige andere Steine, Sümpfe und Abgründe gibt.

Lucas de Vil · 26. April 2010, 10:48

Ich persönlich sehe jetzt nicht allzu viel Falsches in dem zitierten Abschnitt.

Der Part, der hier offenbar für die Verwirrung sorgt, sieht den im Kapitel wie folgt aus:

Quellcode

#import <Foundation/Foundation.h>
@interface MyClass : NSObject {
MyClass* field1;
MyClass* field2;
}
@property (assign) MyClass* field1;
@property (assign) MyClass* field2;
@end
---
MyClass* obj = [[MyClass alloc] init]; // A: A.rc = 1
obj.field1 = [[MyClass alloc] init]; // B: B.rc = 1
obj.field2 = [[MyClass alloc] init]; // C: C.rc = 1
obj.field2.field1 = [obj.field1 retain]; // B.rc = 2
obj.field2.field2 = [obj.field1 retain]; // B.rc = 3
[obj.field1 release]; // B.rc = 2
obj.field1 = nil;
[obj.field2.field2 release]; // B.rc = 1
obj.field2.field2 = nil;
[obj.field2.field1 release]; // B.rc = 0, B wird aus dem Speicher entfernt
obj.field2.field1 = nil;

Alles anzeigen

Man sieht hier sehr schön: im Buch werden Assign-Setter genutzt, keine Retain- oder Copysetter.
Es wird nicht obj.field2 ausgetauscht, sondern obj.field2.field2, so dass sich via obj.field2 noch alles schick freigeben lässt.

Also ist das Ganze faktisch richtig, das Zerreißen des Quelltextes ist nur suboptimal.

Lucas de Vil · 26. April 2010, 10:56

Amin Negm-Awad schrieb:

Wenn man so etwas liest:
NSString* string1 = [[[NSString alloc] initWithString: @"Hello"] retain];
fragt man sich schon, ob da jemand das Ding wirklich richtig vermittelt.

Im Kontext schon.

Quellcode

NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSString* string1 = [[[NSString alloc] initWithString: @"Hello"] retain];
NSString* string2 = [[NSString alloc] initWithString: @"World"];
NSString* string3 = [NSString stringWithString: @"Today"];
[string1 autorelease];
NSLog(string1);
NSLog(string2);
NSLog(string3);
[string2 release];
[string1 autorelease];
[pool release];

Alles anzeigen

In beiden Fällen des Auftretens dieses offenbaren Schwachsinns wird die Funktion des ARP erklärt.

Dieses Buch ist schlicht nicht zum flüchtigen Durchschauen geeignet, sondern muss wirklich aufmerksam und mehrmals gelesen werden.
Grobe Schnitzer, die nicht von den Autoren selbst als 'Schwachsinn' enttarnt wurden, habe ich nicht gefunden.

Man kann sie lediglich ob des fehlenden Formatstrings in NSLog() verprügeln wollen.

Amin Negm-Awad · 26. April 2010, 11:03

Nein, im Kontext nicht. Ich hatte ja schon versucht zu erklären, dass es keine Kontext von Verweisen gibt. Jeder ist für seine Verweise zuständig. Kontext hin, Kontext her. Das ist das Grundprinzip und daher nicht eine Ungenauigkeit.

Also noch einmal:
Wenn ich in einer Zuweisung für zwei RCs sorge, muss das konzeptionell falsch sein, weil ich nur eine Zuweisung haben. Eine Zuweisung kann nur eine Inhaberschaft begründen, die deshalb nur einmal angezeigt werden muss.

Alles andere ist grundlegend falsch, weil es dem Konzept nicht entspricht. Dass man das reparieren kann, ist klar, weshalb ich das auch geschrieben hatte. Das macht es aber nicht richtig:

"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--."

macmoonshine · 26. April 2010, 11:41

Lucas de Vil schrieb:

Dieses Buch ist schlicht nicht zum flüchtigen Durchschauen geeignet, sondern muss wirklich aufmerksam und mehrmals gelesen werden.
Grobe Schnitzer, die nicht von den Autoren selbst als 'Schwachsinn' enttarnt wurden, habe ich nicht gefunden.

Der Code erinnert mich an die Folge, wo Mr. Bean auf ein Baby, einen Fisch und noch einiges Anderes unfreiwillig aufpassen muss. Zum Schluss geht zwar alles gut aus. Das Ganze ist aber eine sehr wackelige Geschichte.

Der Code funktioniert zwar und hinterlässt auch kein Speicherleck. Er ist aber absolut nicht stabil gegen Erweiterungen und für Anfänger ungeeignet, weil der Ansatz falsch ist.

Die Speicherverwaltung in Objective-C ist, wie es schon Amin geschrieben hat, eben kein Zähler rauf- und runterzählen, auch wenn es technisch so umgesetzt ist. Es ist eine Eigentümerverwaltung. Im Sinne der Datenkapselung ist es uninteressant, ob das mit Reference-Counting oder irgendwie anders gemacht ist. Apple hätte am besten auch auf diese unselige retainCount-Methode verzichtet...

Markus Müller · 26. April 2010, 12:24

Also es wird schon auf das Thema Eigentümerschaft eingegangen - allerdings erst weiter unten.
Insofern würde ich das Buch auch nicht nur aufgrund des aus dem Kontext gerissenen Codebeispiels als Fehlkauf bezeichnen.

Inwieweit das jetzt didaktisch vlt. noch zu verbessern ist, kann ich nicht beurteilen. Lies Dir auf jeden Fall auch noch die Apple-Doku zum Memory Management durch und lese das Kapital danach noch einmal. Nur Geduld, das wird schon.

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

Na, ja, es ist ja generell schwierig ein Buch aufgrund einzelner Textstellen als Fehleinkauf zu bezeichnen. Jedes Buch hat Stärken und Schwächen, jedes hat auch seine Fehler.

Aber soweit man das hier beurteilen kann, sind solche Anweisungen wie oben von mir – natürlich wild – herausgegriffen kein gutes Zeichen. Nicht, weil da ein Fehler liegt, den man wieder reparieren und vielleicht auch erläutern kann. Eher deswegen, weil man als erfahrener Objective-C-Programmierer gar nicht auf die Idee käme, so etwas zu machen.

Lucas de Vil · 26. April 2010, 12:42

Amin Negm-Awad schrieb:

Wenn ich in einer Zuweisung für zwei RCs sorge, muss das konzeptionell falsch sein, weil ich nur eine Zuweisung haben. Eine Zuweisung kann nur eine Inhaberschaft begründen, die deshalb nur einmal angezeigt werden muss.

Es ist konzeptionell falsch und erläutert nur die Funktionsweise.
Die Durchführungsregelungen wurden vorher schon vorgestellt.

Um zu klären, ob man Besitzer eines Objekts ist und welche Verpflichtungen man gegenüber einem Objekt eingeht, sind zusammen mit der Implementierung des Reference Counting einige einfache Verhaltensregeln festgelegt worden:
- Man ist Besitzer eines Objekts, das man »selbst erzeugt« hat.
- Es gelten alle Objekte als »selbst erzeugt«, die durch einen Methodenaufruf entstanden sind, dessen Name mit alloc oder new beginnt oder das Wort copy beinhaltet. All diese »selbst erzeugten« Objekte haben nach der Erzeugung genau einen Besitzer und damit einen Reference Count von 1.
- Wenn man nicht möchte, dass ein Objekt aus dem Speicher entfernt wird, muss man Besitzer des Objekts werden. Was zum Beispiel notwendig ist, wenn ein Objekt während der Verarbeitung durch einen anderen Thread freigegeben werden könnte oder man das Objekt auch über die Ausführung der aktuellen Funktion hinweg benötigt. Erreichen kann man dies, indem man retain an dieses Objekt sendet.
- Für alle Objekte, die man besitzt, hat man auch die Verantwortung, sie mit release wieder freizugeben, falls man asie nicht weiter benötigt. Diese Freigabe sollte auch immer so früh wie möglich geschehen, um nicht unnötig Speicher zu verschwenden.
- Alle Objekte, die man hingegen nicht besitzt, muss man auch nicht wieder freigeben.

Vorsicht
War man bereits Besitzer eines Objekts, wird man durch einen erneuten Aufruf von retain zweimaliger Besitzer des Objekts, was dazu führt, dass man auch zweimal die Verantwortung besitzt, dieses Objekt mit release wieder freizugeben.

Nichts Anderes erklärt das. Das Beispiel mag strange sein (Informatiker halt), dennoch ist es richtig.
Ich verstehe die Texte so, als sollte -retain und -release des Eigentümers ausbalanciert sein. Ich lese nirgendwo, dass man permanent prüfen soll, ob der RetainCount stimmt.

Amin Negm-Awad schrieb:

Eine Zuweisung kann nur eine Inhaberschaft begründen, die deshalb nur einmal angezeigt werden muss.

Korrekt. Blöd nur, dass sie mehrmals angezeigt werden kann.

HansGerber: Du hast offenbar Probleme damit, diesen Informatikstil korrekt zu verstehen.
Es ist halt alles ziemlich funktional und korrekt dargestellt, doch wie in der Informatik üblich weit ab der Realität und viel zu komplex.
Nimm oberen Punkte aus dem Buch, kopiere sie dir, vergiss +new und nimm das nächste Kapitel.
Halte dich nur an die oben genannten Regeln und kümmer dich erst mal nicht um den RetainCount.
Wende die Regeln konsequent an. Wenn eine Methode bei deinen Objekten weder alloc noch copy beinhaltet, gib das Objekt autoreleased zurück.

Wenn du wissen möchtest, was 'unter der Haube' passiert, schau in dieses Tutorial.
Du schaffst das.

Wie du siehst, gibt es hier gewisse Uneinigkeiten darüber was richtig im Sinne von Funktional und richtig im Sinne von Guter Stil ist.
Deshalb nimm einfach die Regeln auf. Die beschreibt auch Apple selbst. Bei konkreten Problemen kannst du ja das Projekt hochladen und nachfragen.

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

Lucas de Vil schrieb:

Amin Negm-Awad schrieb:

Wenn ich in einer Zuweisung für zwei RCs sorge, muss das konzeptionell falsch sein, weil ich nur eine Zuweisung haben. Eine Zuweisung kann nur eine Inhaberschaft begründen, die deshalb nur einmal angezeigt werden muss.

Es ist konzeptionell falsch und erläutert nur die Funktionsweise.
Die Durchführungsregelungen wurden vorher schon vorgestellt.

Das ist falsch. Es gibt keine Funktionsweise der doppelten Inhaberschaft, weil es keine doppelte Inhaberschaft gibt.

Lucas de Vil schrieb:

[…]Vorsicht
War man bereits Besitzer eines Objekts, wird man durch einen erneuten Aufruf von retain zweimaliger Besitzer des Objekts, was dazu führt, dass man auch zweimal die Verantwortung besitzt, dieses Objekt mit release wieder freizugeben.

Nichts Anderes erklärt das. Das Beispiel mag strange sein (Informatiker halt), dennoch ist es richtig.

Nein, das erläutert den Fehler. Man wird nicht zweimaliger Besitzer eines Objektes. Deshalb muss man auch nicht vorsichtig sein, dass man es zweimal freigeben muss. Es ist eben wie bereits nunmehr zweimal von mir dargestellt: RC ist nicht einfach RC++ und RC--. Genau diesem Fehler unterliegen die aber.

Lucas de Vil schrieb:

Ich verstehe die Texte so, als sollte -retain und -release des Eigentümers ausbalanciert sein. Ich lese nirgendwo, dass man permanent prüfen soll, ob der RetainCount stimmt.

Das hat auch keiner behauptet. Es wurde behauptet, dass RC eben mehr ist als einfach zu balancieren. Ich hatte das sogar explizit nun mehr schon zweimal geschrieben. Dass du das nicht liest, ist ja nun nicht mein Problem.

Man kann das anhand der Balancierung erklären, ich halte das sogar für sinnvoll, weil es leicht vorstellbar für den Leser ist. Das ändert aber nichts daran, dass dieser Code und Sätze wie "War man bereits Besitzer eines Objekts, wird man durch einen erneuten Aufruf von retain zweimaliger Besitzer des Objekts, was dazu führt, dass man auch zweimal die Verantwortung besitzt, dieses Objekt mit release wieder freizugeben." zeigen, dass die Autoren RC nicht verstanden haben.

Man wird nicht zweimaliger Besitzer eines Objektes. Deshalb muss man auch nicht vorsichtig sein, dass man es zweimal freigeben muss.

Amin Negm-Awad schrieb:

Eine Zuweisung kann nur eine Inhaberschaft begründen, die deshalb nur einmal angezeigt werden muss.

Lucas de Vil schrieb:

Korrekt. Blöd nur, dass sie mehrmals angezeigt werden kann.

Und was sagt uns das Dass man durch 0 dividieren kann? Oder willst du mir sagen, dass wenn man Fehler machen kann, man sie nicht nur machen sollte, sondern auch noch vermitteln sollte?

Lucas de Vil schrieb:

[…]

HansGerber · 26. April 2010, 13:15

@Lukas de Vil

HansGerber: Du hast offenbar Probleme damit, diesen Informatikstil korrekt zu verstehen.

Das ist ganz offensichtlich so. Ich hatte ja auch schon erwähnt, dass, je mehr ich gelesen habe, nur umso verwirrter war.
Also von wegen "Lerne es von Grund auf richtig", das wird mit dem Buch (bei mir zumindest) nix. Die Beispiel sorgen im Moment nur für Konfusion.

Im Moment bin ich grade an Deinem vorigen Post bzw. kommentierten Beispiel-Code :

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

Das scheint mir relativ zentral fürs Verständnis zu sein, wann, wo bzw. ob ein Leck entsteht, hat aber die Verständnis-Barriere der Grosshirnrinde noch nicht durchdrungen.
Im Moment nur soviel wg. des (mehrfachen) Hinweises auf den ARP :
Wenn all diese Objekte im obigen Code gleich autoreleased wären, gäbe es kein Speicherleck, weil auf jeden Fall eine Referenz auf den ursprünglichen Speicherbereich freigegeben wird (und damit auch y & z freigegeben werden (können)) ?

Hans

Amin Negm-Awad · 26. April 2010, 13:46

Autorelease anstelle von Release verhindert das versehentliche Vergessen des Releases. Außerdem gibt es bestimmte Fallgestaltungen, in denen es gar nicht anders geht. Da bvist du aber noch nicht.

Mit anderen Worten: Autorelease anstelle von Release verbessert nicht das Verständnis.

macmoonshine · 26. April 2010, 14:09

Markus Müller schrieb:

Also es wird schon auf das Thema Eigentümerschaft eingegangen - allerdings erst weiter unten.
Insofern würde ich das Buch auch nicht nur aufgrund des aus dem Kontext gerissenen Codebeispiels als Fehlkauf bezeichnen.

Ich habe mich nicht nur auch den Einzeiler bezogen und der Ausdruck Eigentümer befindet sich nicht in der Leseprobe. Ich finde den Ansatz zur Erklärung der Speicherverwaltung für Anfänger zu kompliziert und ein Leser wurde, wie ja dieser Thread zeigt, auch schon ordentlich ins schleudern gebracht. Hans beschäftigt sich mit Referenzzählern aber nicht mit der Speicherverwaltung. Für einen Anfänger ist das Buch, was die Speicherverwaltung angeht nicht geeignet - also ein Fehlkauf.

Wie ich bereits geschrieben habe, ist die Speicherverwaltung elementar, um stabile Objective-C-Programme zu schreiben.

Markus Müller schrieb:

Inwieweit das jetzt didaktisch vlt. noch zu verbessern ist, kann ich nicht beurteilen. Lies Dir auf jeden Fall auch noch die Apple-Doku zum Memory Management durch und lese das Kapital danach noch einmal. Nur Geduld, das wird schon.

Das bestätigt doch genau meine These. Wenn er sich für die Speicherverwaltung die Apple-Doku durchlesen soll, wozu braucht er dann das Buch?

Markus Müller · 26. April 2010, 14:21

@Hans Gerber:
Wenn Du mit dem Buch nicht zurechtkommst, schaue Dir doch in einer Buchhandlung mal andere Cocoa-Bücher an.
Ich habe seinerzeit mit dem Hillegass und einer älteren Ausgabe von Objective-C und Cocoa (Rodewig/Amin Negm-Awad) gelernt. Beide Bücher lohnen sich. Das Thema Speicherverwaltung fand ich in Amins Buch umfangreicher und gut erklärt. Allerdings ist es ganz wichtig, dass Du viel übst und das gelernte Wissen ausprobierst. Wenn Du etwas falsch machst, merkst Du es beim Üben meistens sehr schnell und der Lerneffekt ist umso grösser. Um es nochmal zu sagen: das Durcharbeiten der Bücher allein bringt Dich nicht weiter, probiere es in kleinen Projekten am Rechner aus.

In der Praxis ist die Speicherverwaltung eigtl. ganz einfach. Die benötigte Infrastruktur steckt in den gettern/settern bzw. CAs. Die zugrunde liegende Funktionsweise ist immer die gleiche. Ein Gefühl dafür bekommst Du zuallererst durch Übung (Literaturhinweise hast Du ja jetzt, falls Du mit Deinem Buch überhaupt nicht mehr weitermachen möchtest - scheint mir aber unnötig).

Markus Müller · 26. April 2010, 14:34

macmoonshine schrieb:

Ich habe mich nicht nur auch den Einzeiler bezogen und der Ausdruck Eigentümer befindet sich nicht in der Leseprobe. Ich finde den Ansatz zur Erklärung der Speicherverwaltung für Anfänger zu kompliziert und ein Leser wurde, wie ja dieser Thread zeigt, auch schon ordentlich ins schleudern gebracht. Hans beschäftigt sich mit Referenzzählern aber nicht mit der Speicherverwaltung. Für einen Anfänger ist das Buch, was die Speicherverwaltung angeht nicht geeignet - also ein Fehlkauf.

Schau mal zu Absatz 8.3.1 Besitz und Freigabe von Objekten
Ist doch Quatsch und hilft Hans nicht wirklich weiter, wenn wir jetzt hier über Formulierungen zanken (Eigentünerschaft/Besitz).

macmoonshine schrieb:

Das bestätigt doch genau meine These. Wenn er sich für die Speicherverwaltung die Apple-Doku durchlesen soll, wozu braucht er dann das Buch?

Die Apple Doku zum Memory Management sollte er in jedem Fall lesen, ganz egal welches Buch er benutzt.
Ist aber auch egal, ich will wirklich nicht rumstreiten - finde ja auch, dass es einsteigerfreundlichere Cocoa-Bücher gibt. Dennoch muss das Buch deshalb kein Fehlkauf sein.

Lucas de Vil · 26. April 2010, 14:43

Amin Negm-Awad schrieb:

Es gibt keine Funktionsweise der doppelten Inhaberschaft, weil es keine doppelte Inhaberschaft gibt.
[...]
Man wird nicht zweimaliger Besitzer eines Objektes. Deshalb muss man auch nicht vorsichtig sein, dass man es zweimal freigeben muss.

Amin Negm-Awad schrieb:

Eine Zuweisung kann nur eine Inhaberschaft begründen, die deshalb nur einmal angezeigt werden muss.

Lucas de Vil schrieb:

Korrekt. Blöd nur, dass sie mehrmals angezeigt werden kann.

Und was sagt uns das Dass man durch 0 dividieren kann? Oder willst du mir sagen, dass wenn man Fehler machen kann, man sie nicht nur machen sollte, sondern auch noch vermitteln sollte?

Ja wat denn nun? Entweder gibt es keine doppelte Besitzerschaft eines Objektes, oder eben doch.

Quellcode

[myString retain];
//Do Something with myString;
// 300 Zeilen Code
[myString retain];
//Do Something with MyString;
// 300 Zeilen Code
[myString retain];
//Do something with MyString;
[myString release];

Habe ich jetzt eine dreifache Inhaberschaft gehabt oder nicht?
Habe ich nach dem -release noch eine doppelte Inhaberschaft oder nicht?
Muss ich alle meine Inhaberschaften aufräumen oder nicht?

Ja, das Beispiel ist an den Haaren herbeigezogen, konstruiert und realitätsfern.
Nichts desto trotz funktioniert das genauso wie

Quellcode

NSArray* testArray = [[[NSArray array] retain] autorelease];

was ebenfalls totaler Schwachsinn ist.

Von den Grundlagen über die Funktionalität des Ganzen sehe ich da keine Fehler.
Das es verwirrend sein kann stelle ich nicht in Frage.

Deshalb soll HansGerber sich die 'Guidelines' ausdrucken und schauen, wie die Jungs in den nächsten Kapiteln weitermachen.
Wenn sie die über schräg konstruierte Beispiele erläuterte Speicherverwaltung im Folgenden korrekt nutzen sehe ich da keine Probleme.

Lucas de Vil · 26. April 2010, 14:54

HansGerber schrieb:

Wenn all diese Objekte im obigen Code gleich autoreleased wären, gäbe es kein Speicherleck, weil auf jeden Fall eine Referenz auf den ursprünglichen Speicherbereich freigegeben wird (und damit auch y & z freigegeben werden (können))?

Jein.
-autorelease meldet dem Autoreleasepool, dass diese Instanz bitte bei Zeiten einmal freigegeben werden möchte.
Ich weiß nicht genau ob beim Verlassen oder beim Wiedereintritt in die Runloop, jedenfalls wird irgendwann der Autoreleasepool dafür sorgen, dass alle in ihm enthaltende Instanzen ein -release bekommen. Die Implementation ist dabei recht egal.

In diesem Fall würde das Nutzen des ARP dir helfen, y und z loszuwerden.

Den von dir geposteten Code inklusive retain-Setter habe ich dem Kapitel aber nicht gefunden.
Dort werden assign-Setter genutzt und nicht die Unterobjekte der zweiten sondern der dritten Ebene ausgetauscht.
In dem Fall kann es passieren, dass dir der ARP die Instanzen wegtritt, obwohl du sie noch brauchst.

Wie Amin schon sagte: das Nutzen des Autoreleasepools verbessert nicht das Verständnis.

Nimm dir die Regeln zu Herzen und mach damit in den nächsten Kapiteln weiter.
Falls dir die nicht gefallen, nimm die Regeln von Apple.
developer.apple.com/iphone/lib…ore/MemoryManagement.html
Immer schick anwenden, das ist die halbe Miete. Den Rest bekommst du durch lustige Probleme in den Progrämmchen irgendwann selbst gelöst, welche nie entstanden wären, hättest du die Regeln richtig angewandt.

Amin Negm-Awad · 26. April 2010, 16:02

Lucas de Vil schrieb:

Amin Negm-Awad schrieb:

Es gibt keine Funktionsweise der doppelten Inhaberschaft, weil es keine doppelte Inhaberschaft gibt.
[...]
Man wird nicht zweimaliger Besitzer eines Objektes. Deshalb muss man auch nicht vorsichtig sein, dass man es zweimal freigeben muss.

Amin Negm-Awad schrieb:

Eine Zuweisung kann nur eine Inhaberschaft begründen, die deshalb nur einmal angezeigt werden muss.

Lucas de Vil schrieb:

Korrekt. Blöd nur, dass sie mehrmals angezeigt werden kann.

Und was sagt uns das Dass man durch 0 dividieren kann? Oder willst du mir sagen, dass wenn man Fehler machen kann, man sie nicht nur machen sollte, sondern auch noch vermitteln sollte?

Ja wat denn nun? Entweder gibt es keine doppelte Besitzerschaft eines Objektes, oder eben doch.

Es gibt keine. Das schreibe ich jetzt eigentlich schon die gesamte Zeit. Wieso liest du es nicht einfach?

Der einzige, der von mehrfachen Inhaberschaften spricht, bist du – und das Buch. Da macht ihr wohl denselben Fehler.

Lucas de Vil schrieb:

Quellcode

[myString retain];

//Do Something with myString;

// 300 Zeilen Code

[myString retain];

//Do Something with MyString;

// 300 Zeilen Code

[myString retain];

//Do something with MyString;

[myString release];

Habe ich jetzt eine dreifache Inhaberschaft gehabt oder nicht?

Du hast keine. Es gibt keine dreifache Inhaberschaft. (Natürlich kann es verschiedene Inhaberschaften von verschiedenen Objekten über verschiedene Verweise geben. Aber nicht desselben Verweises.)

Du hast aber dreimal den RC erhöht, obwohl nur eine Inhaberschaft vorliegt. Das ist der Fehler.

Lucas de Vil schrieb:

Habe ich nach dem -release noch eine doppelte Inhaberschaft oder nicht?

Nein, hast du nicht, weil es keine doppelte Inhaberschaft gibt.

Lucas de Vil schrieb:

Muss ich alle meine Inhaberschaften aufräumen oder nicht?

Nein, du darfst es gar nicht erst mehrfach retainen.

Lucas: "Wenn Sie Ihren Laptop in die gefüllte Badewanne werfen, dann muss ich ihn abtrocknen."
Amin: "Nein du sollst ihn gar nicht in die gefüllte Badewanne werfen."
Lucas wirft den Laptop in die gefüllte Badewanne. "Ja was denn nun? Jetzt muss ich ihn doch abtrocknen, oder nicht?"

Lucas de Vil schrieb:

Ja, das Beispiel ist an den Haaren herbeigezogen, konstruiert und realitätsfern.
Nichts desto trotz funktioniert das genauso wie

Quellcode

NSArray* testArray = [[[NSArray array] retain] autorelease];

was ebenfalls totaler Schwachsinn ist.

Nein, es nicht nicht an den Haare herbeigezogen, konstruiert und realitätsfern, sondern fehlerhaft.

Es gibt keine mehrfache Inhaberschaft. Ein Verweis kann nur einmal besitzen. Einfache Regel, einfache Aussage, einfach anzuwenden. Ich verstehe immer noch nicht, wo du da genau scheiterst.

Ist eigentlich einfach.

Lucas de Vil schrieb:

Von den Grundlagen über die Funktionalität des Ganzen sehe ich da keine Fehler.

Der Fehler liegt darin, dass es keine mehrfache Inhaberschaft gibt. Ob du den siehst, ist ziemlich gleichgültig.

Lucas de Vil schrieb:

Das es verwirrend sein kann stelle ich nicht in Frage.

Es ist schlicht falsch.

Lucas de Vil schrieb:

Deshalb soll HansGerber sich die 'Guidelines' ausdrucken und schauen, wie die Jungs in den nächsten Kapiteln weitermachen.
Wenn sie die über schräg konstruierte Beispiele erläuterte Speicherverwaltung im Folgenden korrekt nutzen sehe ich da keine Probleme.

Es kann sein, dass du da keine Probleme siehst.

macmoonshine · 26. April 2010, 16:16

Markus Müller schrieb:

macmoonshine schrieb:

Ich habe mich nicht nur auch den Einzeiler bezogen und der Ausdruck Eigentümer befindet sich nicht in der Leseprobe. Ich finde den Ansatz zur Erklärung der Speicherverwaltung für Anfänger zu kompliziert und ein Leser wurde, wie ja dieser Thread zeigt, auch schon ordentlich ins schleudern gebracht. Hans beschäftigt sich mit Referenzzählern aber nicht mit der Speicherverwaltung. Für einen Anfänger ist das Buch, was die Speicherverwaltung angeht nicht geeignet - also ein Fehlkauf.

Schau mal zu Absatz 8.3.1 Besitz und Freigabe von Objekten
Ist doch Quatsch und hilft Hans nicht wirklich weiter, wenn wir jetzt hier über Formulierungen zanken (Eigentünerschaft/Besitz).

Gut, mit dem Besitz hast Du recht. Aber darum ging es mir auch nicht. Das Buch erklärt das Was mit dem Wie. Es wird erst geschrieben, wie das Reference-Counting funktioniert und (vielleicht) danach wie es anzuwenden ist. Das führt dazu, dass sich Hans um den Wert des Referenzenzählers Gedanken macht, obwohl ihn der nichts angeht. Die Stelle in der Apple-Doku, auf die Du Dich wahrscheinlich beziehst und die in dem Buch auf deutsch (nahezu wortwörtlich) wiedergegeben ist. Erklärt die Speicherverwaltung ganz ohne Referenzenzählerei. Das sollte ein Anfänger zuerst lernen.

Markus Müller schrieb:

macmoonshine schrieb:

Das bestätigt doch genau meine These. Wenn er sich für die Speicherverwaltung die Apple-Doku durchlesen soll, wozu braucht er dann das Buch?

Die Apple Doku zum Memory Management sollte er in jedem Fall lesen, ganz egal welches Buch er benutzt.
Ist aber auch egal, ich will wirklich nicht rumstreiten - finde ja auch, dass es einsteigerfreundlichere Cocoa-Bücher gibt. Dennoch muss das Buch deshalb kein Fehlkauf sein.

Ich meine hier Fehlkauf in dem Sinn, dass es - zumindest an dieser Stelle - für einen Anfänger zu kompliziert ist. Für den Anfänger ist es ein Fehlkauf, weil er genau so viel Zeit und Arbeit für das Verständnis aufbringen muss, wie für die Apple-Doku, die ja keinen Anspruch darauf erhebt, anfängertauglich zu sein. Außerdem bringt das Buch den unerfahrenen Leser durch seine kruden Programmbeispiele noch auf falsche Fährten. Auch, wenn der Code als Negativbeispiel gemeint gewesen sein sollte, so ist doch beim Leser Hans Das steht doch so in einem Buch. hängen geblieben.

Amin Negm-Awad · 26. April 2010, 16:21

Lucas de Vil schrieb:

HansGerber schrieb:

Wenn all diese Objekte im obigen Code gleich autoreleased wären, gäbe es kein Speicherleck, weil auf jeden Fall eine Referenz auf den ursprünglichen Speicherbereich freigegeben wird (und damit auch y & z freigegeben werden (können))?

Jein.
-autorelease meldet dem Autoreleasepool, dass diese Instanz bitte bei Zeiten einmal freigegeben werden möchte.
Ich weiß nicht genau ob beim Verlassen oder beim Wiedereintritt in die Runloop, jedenfalls wird irgendwann der Autoreleasepool dafür sorgen, dass alle in ihm enthaltende Instanzen ein -release bekommen. Die Implementation ist dabei recht egal.

Nein, das ist sie nicht. Natürlich kann einem nicht egal sein, wann die Instanzen verschwinden. Wenn man das nicht wüsste, dürfte man den ARP überhaupt nicht benutzen. Es ist auch kein Implementierungsdetail, weil es Wirkungen nach außen hat.

Die Instanzen verschwinden frühestens dann, wenn die Instanz des ARP selbst verschwindet oder ein -drain erhält. Das weiß man ganz genau und es ist wichtig, dieses zu wissen.

Lucas de Vil schrieb:

In diesem Fall würde das Nutzen des ARP dir helfen, y und z loszuwerden.

Den von dir geposteten Code inklusive retain-Setter habe ich dem Kapitel aber nicht gefunden.
Dort werden assign-Setter genutzt und nicht die Unterobjekte der zweiten sondern der dritten Ebene ausgetauscht.
In dem Fall kann es passieren, dass dir der ARP die Instanzen wegtritt, obwohl du sie noch brauchst.

Ich weiß jetzt nicht genau, von welchem Code du sprichst, da hier ja schon einiger herumfliegt.

Aber soweit ich das überblicke ist dieses Aussage in keinem Falle richtig. Eine Instanz wird frühestens bei dem -release auf den ARP vom ARP gelöscht. Wenn ich keinen Code übersehen habe, dann ist das stets die letzte Anweisung. Also kann da nichts passieren.

Lucas de Vil schrieb:

[…]