retainCount

bauwerk · 11. August 2010, 17:07

Hi,

habe früher bisle Basic gemacht und bin - da ich nach 4 Jahren Apple so langsam auch mal was natives machen will - über JavaScript, PHP und etwas echtem Java dann nun auf Cocoa/Objective C gestoßen und fange von Null an, könnte man sagen. Ich habe mir das Buch Objective-C und Cocoa von Rodewig und Negm-Awad (2. Auflage) besorgt - ich denke damit bin ich hier an der richtigen Stelle.

Und ich habe auch schon die erste Frage: Ich habe jetzt diese Klasse Person geschrieben. Ich habe in der main-Methode eine Variable "aPerson" erzeugt. Allokiert und initialisiert und kriege den retainCount 1. Alles in Butter.

Frage 1: Durch das Allokieren und Initialisieren reserviere ich mir speicher fürs Objekt und verknüpfe dieses Objekt nun mit der Variable "aPerson". Habe ich das richtig verstanden?

Jetzt mache ich das gleiche mit einem Objekt der Klasse NSString. Also

Quellcode

NSString* test = [[NSString alloc] init];
NSLog(@"testRetainCount %d", [test retainCount]);

Frage 2: Wieso bekomme ich da jetzt einen retainCount von 2147483647 ?
Frage 3: Hat diese Zahl eine besondere Bedeutung?

Grüße,

Bauwerk

Amin Negm-Awad · 11. August 2010, 17:25

a) Ja
b) + c) Du erzeugst einen leeren String. Tatsächlich optimiert das Cocoa, weil man ja ständig leere Strings hat. Daher gibt er dir ein bereits auf Vorrat erzeugtes Objekt zurück. Dies darf natürlich nie entfernt werden, weshalb es einen besonderen Retain-Count bekommt, der die Bedeutung: "Bleib bei mir" hat.

bauwerk · 11. August 2010, 17:36

Huch, da antwortet direkt der Autor. Es ist, als könnte man das Buch fragen :). Tolles Buch, Glückwunsch.

Also cocoa legt schonmal beim starten der Anwendung x viele Objecte NSString an und verwendet die an allen möglichen Stellen immer wieder. Richtig? Für welche Klassen gilt das denn noch?

darkangel · 11. August 2010, 17:37

bauwerk schrieb:

Also cocoa legt schonmal beim starten der Anwendung x viele Objecte NSString an und verwendet die an allen möglichen Stellen immer wieder.

Das sind nicht x Objekte sondern eins mit einem sehr hohen retainCount. Jedes mal wenn sich der retainCount erhöht, wird also kein neues Objekt angelegt

bauwerk · 11. August 2010, 18:00

aha, hm. Heißt: String erzeugt, Speicher futsch bis auf nimmer wiedersehen.

Amin Negm-Awad · 11. August 2010, 18:15

bauwerk schrieb:

Huch, da antwortet direkt der Autor. Es ist, als könnte man das Buch fragen . Tolles Buch, Glückwunsch.

Danke

bauwerk schrieb:

Also cocoa legt schonmal beim starten der Anwendung x viele Objecte NSString an und verwendet die an allen möglichen Stellen immer wieder. Richtig? Für welche Klassen gilt das denn noch?

Ja, es werden "beim Start" Instanzen erzeugt und auch sonst noch kann es passieren, dass welche auf Vorrat erzeugt werden. Du kannst dir mal eine NSNumber-Instanz mit dem Wert 3 erzeugen – und dann noch eine – und dann noch eine … Wieso sollte jedes Mal eine neue erzeugt werden. Es wird mutmaßlich auch weitere Strings geben, die auf Verdacht gehalten werden. @"pm", @"Montag" usw. sind solche Kandidaten. Ansonsten wird generell kein neues Objekt erzeugt, wenn du eine unveränderliche Instanz hast und die kopierst oder daraus neue Instanzen herstellt. Dazu gibt es auch ein Beispiel im Buch.

In welchen Fällen das so ist? Keine Ahnung. Wieso interessiert es dich.

bauwerk schrieb:

aha, hm. Heißt: String erzeugt, Speicher futsch bis auf nimmer wiedersehen.

Ja. Was weniger Speicher verbraucht, als das immer wieder zu tun. Ansonsten ist Speicher so ziemlich die günstigste Ressource im Computer. Da sollte man also zuletzt sparen.

Amin Negm-Awad · 11. August 2010, 18:17

darkangel schrieb:

bauwerk schrieb:

Also cocoa legt schonmal beim starten der Anwendung x viele Objecte NSString an und verwendet die an allen möglichen Stellen immer wieder.

Das sind nicht x Objekte sondern eins mit einem sehr hohen retainCount. Jedes mal wenn sich der retainCount erhöht, wird also kein neues Objekt angelegt

Nicht mit einem ziemlich hohen, sondern wirklich mit einem besonderen. Der sollte sich nie verändern.