Alloc oder nicht?

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

  • Alloc oder nicht?

    Hallo OSX Entwickler,
    Ich bin noch ein Neuling in Sachen Cocoa und Objective C.
    Ich habe mir schon viele Tutorials zu diesen Themen angesehen, aber diese waren alle etwas älter (Xcode 3).
    Wie es der Zufall will, steige ich gerade zu dem Zeitpunkt in die Xcode Programmierung ein, als ARC erscheint.
    Ich weis, das mit init die init-Methode des zu erstellenden Objekts aufgerufen wird und mit alloc wird Speicher reserviert.

    Nun meine Frage, kann mit bitte jemand den Unterschied zwischen diesen beiden Objekterzeugungen erklären.

    Quellcode

    1. myClass *myObject;


    Quellcode

    1. myClass *myObject = [[myClass alloc] init];


    Ich kann mir den Unterschied schon denken.
    Bei der unteren Objekterzeugung wird Speicher reserviert und die init Methode wird aufgerufen,
    bei der oberen Objekterzeugung nicht. Kann das Objekt überhaupt existieren, wenn es keinen Speicher hat?
    Wie kann es erstellt werden, wenn die init Methode nicht ausgeführt wird?
    Muss überhaupt Speicher reserviert werden, wenn man mit ARC arbeitet?

    Kann man nicht das Objekt auch so erstellen?

    Quellcode

    1. myClass *myObject = [myClass init];
  • aslo, erstens beginnen klassen mit großem buchstaben: MyPerson!

    MyPerson *myObject; ist nur ein pointer. der zeigt irgendwohin. es wird kein speicher bereitgestellt und auch kein objekt erstellt oder initialisiert.

    [MyPerson init] geht nicht. du musst vorher mit alloc speicher allozieren.

    [MyPerson person] kann man verwenden (wenn man es im plementiert). person ist dann aber ein "Convenience Allocator" welcher eben nur das alloc-init-autorelease aufruft.
  • Wohin zeigt dieser Pointer?
    Angenommen folgendes Beispiel:

    Quellcode

    1. NSString *myString1;
    2. NSString *myString2 = [[NSString alloc] init];
    3. // Fall 1
    4. myString1 = @"Text";
    5. myString2 = @"Text";
    6. // Fall 2
    7. myString1 = anotherString;
    8. myString2 = anotherString;


    Zuerst zu Fall 1:
    Der myString2 sollte doch dann in seinem eigenen Speicher "Text" stehen haben und was ist mit dem myString1, wenn der nur ein Pointer ist?

    Zu Fall 2:
    Der myString2 sollte doch dann in seinem eigenen Speicher den Text von anotherString stehen haben und der myString1 sollte auf die gleiche Adresse, wie der anotherString zeigen, oder?
  • zu dein fall 1:
    @"Text" ist gleichzusetzen mit [NSString stringWithString:@"Text"];

    fall2
    myString ist dann gleich anotherString (zeigt auf den gleichen speicherort)

    PS: du kannst dir mit NSLog(@"%p", myString); angucken auf welche Adresse sie zeigen :)

    PPS: lass ARC, ich find diesen neumodischen quatsch unnötig. Das macht meiner Meinung nach aus Entwicklern, Anwender.
    ich will mich nicht auf Automaisches Counting verlassen, sondern Selber die Kontrolle behalten weil "Ich" weis am besten ob ich ein Objekt noch brauch oder nicht :)
    俺の世界にようこそ
  • mit

    Quellcode

    1. myString1=@"Text";


    weißt Du den Compiler an selber Speicher zu allozieren. Dieser wird einmalig beim Programmstart angelegt und bei Programmende freigegeben. Dafür ist der aber eben auch nicht veränderbar. (Naja mit direkten Zeigeroperationen schon aber es ist halt nicht dafür gedacht): Deshalb handelt es sich hierbei eigentlich um eine Konstante.

    Wenn du string2 zuerst einen Speicher zuweist mit alloc und init und dann den Text mit obiger Zeile, dann würdest du den vorher mit alloc angeforderten Speicher nicht wieder freigeben, die Referenz daraus (nämlich der Zeiger string1) aber auf einen anderen Speicher zeigen lassen. Damit wäre der vorher angeforderte Speicher für immer verloren da er für das System als belegt gekennzeichnet ist und er daher nicht mehr von anderen benutzt werden darf, du selber ihn aber auch nicht mehr benützen kannst da du keinen Zeiger darauf mehr hast. Das nennt man dann einen Speicherfressern oder Leak. Wenn du da viel von machst wirst Du dich wundern warum bei Benutzung Deiner App dein Rechner immer langsamer und langsamer wird bis er irgendwann ganz einfriert.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)