Was passiert bei alloc ohne init mit dem Retain Count

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Was passiert bei alloc ohne init mit dem Retain Count

    Hallo Zusammen,

    ich habe eine Frage, ich versuche das "alte" Speicher-Management zu verstehen. D.h. ich verwende kein
    automatische Reference Counting.

    Unzwar bekomme ich bei folgendem Code:

    NSMutableString *string1 = [NSMutableString alloc];
    NSLog(@"Retain Counter ist %i",[string1 retainCount]);

    eine Ausgabe mit:

    Retain Counter ist -1


    Jetzt verstehe ich nicht warum der Counter auf -1 steht? Erwarten würde ich 1.
    Somit stellt für mich die Frage. Was macht Alloc und was macht init genau?

    Danke für Antworten.

  • Die Klassenmethode alloc reserviert den Speicher für das Objekt. Initilisiert wird der erst über init. Das Einzige, was Du mit einem solchen Objekt machen darfst, ist es zu initialisieren.

    Abgesehen davon gibt es nichts Unintessanteres als den konkreten Retaincount eines Objekts. Dieser Wert hat überhaupt keine Aussagekraft.
    „Meine Komplikation hatte eine Komplikation.“

  • Ich danke dir für die Antwort. Doch leider habe ich das mit Retain Counter noch nicht ganz verstanden. Um genau zu sein, was Alloc mit dem retain counter macht.
    Mein Verständnis war. Mit Alloc reserviere ich einen Speicherplatz und referenziere auf diesen Speicherplatz und müsste somit nach alloc einen retain counter von 1 erhalten.
    Die Init-Methode wiederum setzt die Initialisierungswerte.

    Ist der Retain Counter nicht wichtig zum debuggern ?

  • das init von NSObject regelt das mit dem retaincounter. das wird ja immer über [super init] aufgerufen.

    [ClassName alloc] kannst du mit mit malloc() aus C vergelichen. du reservierst nur speicher, es steht zu dem zeitpunkt aber noch nichts sinnvolles in dem speicher drin. dies wird erst durch init erledigt.

  • pasam schrieb:

    Ist der Retain Counter nicht wichtig zum debuggern ?

    Nein, dieser Ansatz führt Dich vollkommen in die Irre. Wenn Du falsche Retain-Release-Aufrufe oder Speicherlecks finden willst, solltest den Analyzer oder Instruments lesen. Zuallererst solltest Du Dir allerdings die Speicherverwaltungsregeln reinziehen: developer.apple.com/library/io…_ref/doc/uid/20000994-SW1
    „Meine Komplikation hatte eine Komplikation.“

  • pasam schrieb:

    Ich danke dir für die Antwort. Doch leider habe ich das mit Retain Counter noch nicht ganz verstanden. Um genau zu sein, was Alloc mit dem retain counter macht.
    Mein Verständnis war. Mit Alloc reserviere ich einen Speicherplatz und referenziere auf diesen Speicherplatz und müsste somit nach alloc einen retain counter von 1 erhalten.
    Die Init-Methode wiederum setzt die Initialisierungswerte.

    Normalerweise setzt alloc den retain-count auf 1 [1]. Und init verändert ihn nicht. release erkennt am Wert 1 dass es einen dealloc machen muß.
    Es gibt aber den Fall dass die init-Methode schon einen release macht und dann nil (oder ein anderes Objekt mit retain-count 1) zurückliefert.
    Und: es gibt "Class Cluster" und Singleton-Objekte. Bei denen wird der release-counter in der Implementierung außer Betrieb gesetzt und zeigt irreführende Werte [2], was immer wieder zu solchen Diskussionen wie hier führt. NSMutableString gehört zu einem solchen Class-Cluster.


    [1] developer.apple.com/library/ma…Articles/mmPractical.html
    ganz unten "When you create an object, it has a retain count of 1"

    [2] developer.apple.com/library/ma…Articles/mmPractical.html
    noch weiter unten "There should be no reason to explicitly ask an object what its retain count is (see retainCount). The result is often misleading, as..."