Anfängerfrage: Objekterzeugung Buch S.190ff

  • Anfängerfrage: Objekterzeugung Buch S.190ff

    Hallo zusammen.
    Ich arbeite mich gerade durch Amins Buch. Mittlerweile stecke ich in Kapitel 4 bei den Stings.
    Wie ich auf S.190ff gelernt habe, muß ich Objekte erzeugen und initialisieren.
    Irgendwie bekomm ich das ganze aber nicht so auf die Kette.
    Wenn ich Objekte erzeugen und initialiseren muß, warum muß ich dann z.B. ein NSString oder NSNumber Objekt nicht erzeugen, initialisieren und vorallem nachher wieder releasen?
    Kann mir vielleicht jemand den Nebeldunst in meinem Hirn entfernen???

    Danke
    Jens

  • Ich kenne die betreffenden Code-Zeilen nicht, aber da wird entweder eine Konstante z.B. @"irgendwas" erzeugt, was nicht auf dem Heap ist, oder du erzeugst die Strings per Convinience Allocator, welches einen autoreleased String erzeugt.

    Gruss Diskordia
    Ialea iacta est

  • Weil ich z.B. einfach:

    Quellcode

    1. NSString *text = @"Dies ist ein Text";
    schreiben kann. Gut das "@" erzeugt mir ein Objekt. Aber warum muß ich es nicht releasen?
    Es funktioniert auch ohne. Das würde ja auch bedeuten, dass wenn ich z.B. 10 NSStrings hätte, 10 release Nachrichten verschicken müßte?? Und warum zeigt der liebe Amin in seinem Beispielcode dann kein release für NSString an? Ich bin sicher der Amin macht das schon richtig, nur der Empfänger seiner Nachricht (also ich) versteht nicht was er sagen möchte :D

    Jens

  • Original von Diskordia
    Ich kenne die betreffenden Code-Zeilen nicht, aber da wird entweder eine Konstante z.B. @"irgendwas" erzeugt, was nicht auf dem Heap ist, oder du erzeugst die Strings per Convinience Allocator, welches einen autoreleased String erzeugt.

    Gruss Diskordia


    Was ist ein Heap?

  • Ein String welcher mit @"asdf" erzeugt wird, liegt, wie alle Basistypen (int, douple, etc.) auf dem CP Stack und nicht auf dem Heap, der Stack wird am Ende deiner Methode automatisch abgebaut, also musst du dich nicht um die Speicherverwaltung kümmern.
    Wenn du jedoch ein Object per alloc init erzeugst, landet das auf dem Heap, d.h. du hast nur eine Referenz auf eine Speicherstelle wo das Object gespeichert ist und das wird nicht automatisch aufgeräumt.
    Ialea iacta est

  • Original von maultasche
    Original von Diskordia
    Ich kenne die betreffenden Code-Zeilen nicht, aber da wird entweder eine Konstante z.B. @"irgendwas" erzeugt, was nicht auf dem Heap ist, oder du erzeugst die Strings per Convinience Allocator, welches einen autoreleased String erzeugt.

    Gruss Diskordia


    Was ist ein Heap?


    Der dynamische Speicher der CPU.
    Ialea iacta est

  • Original von Diskordia
    Ein String welcher mit @"asdf" erzeugt wird, liegt, wie alle Basistypen (int, douple, etc.) auf dem CP Stack und nicht auf dem Heap, der Stack wird am Ende deiner Methode automatisch abgebaut, also musst du dich nicht um die Speicherverwaltung kümmern.
    Wenn du jedoch ein Object per alloc init erzeugst, landet das auf dem Heap, d.h. du hast nur eine Referenz auf eine Speicherstelle wo das Object gespeichert ist und das wird nicht automatisch aufgeräumt.

    danke fuer diesen beitrag!

    regards,
    buk

  • Hi,
    Original von Diskordia
    Original von maultasche
    Original von Diskordia
    Ich kenne die betreffenden Code-Zeilen nicht, aber da wird entweder eine Konstante z.B. @"irgendwas" erzeugt, was nicht auf dem Heap ist, oder du erzeugst die Strings per Convinience Allocator, welches einen autoreleased String erzeugt.

    Gruss Diskordia


    Was ist ein Heap?


    Der dynamische Speicher der CPU.

    das ist jetzt aber nicht dein Ernst, oder hab ich da ein Smiley übersehen?
    http://pdps.mybrute.com/

  • Original von Diskordia
    Ein String welcher mit @"asdf" erzeugt wird, liegt, wie alle Basistypen (int, douple, etc.) auf dem CP Stack und nicht auf dem Heap

    Das ist so nicht richtig. Ob etwas auf dem Stack oder Heap erzeugt wird, hängt nicht vom Datentyp ab. Stell Dir mal ein Objekt vor, welches einen int oder double als Instanzvariablen hat. Diese Instanzvariablen kommen nicht auf den Stack.

    Auf dem Stack landen lokale Variablen, Parameter von Funktionen, etc. Also Sachen, die nur einen definieren Lebenszeitraum und Speicherplatzbedarf haben. Der Compiler generiert dann entsprechenden Code, der den Speicher auf dem Stack reserviert und auch wieder frei gibt. Stichwort: automatische Variablen.

    Der Heap ist der großen Haufen Speicher, der vom System verwaltet wird. Will ein Programm dort Daten ablegen, muss es vom System eine entsprechende Portion Speicher anfordern. Das passiert auch beim Erzeugen von Objektive-C Objekten durch die Methode +alloc. Deshalb landen alle Objective-C Objekte auf dem Heap.

    Dann gibt es aber noch String-Konstanten, wie "ein C-String" oder eben auch @"NSString". Der Speicher für diese String-Konstanten reserviert auch bereits der Compiler, aber nicht auf dem Stack, sondern im Bereich des Programms selbst. Diese String-Konstanten sind also ab Start des Programms permanent bis zum Beenden des Programms im Speicher vorhanden.

    Und nochmal Grundsätzlich zu der Frage, warum man eine NSString Konstante (@"blablubb") nicht releasen muss. Die Regel ist ja einfach: Objekte, die man mit alloc, new, copy oder mutableCopy erzeugt, muss man auch releasen. So, hat man nun bei der "Erzeugung" einer NSString-Konstanze eine dieser vier Methoden benutzt? Antwort: nein. Also muss ich mich auch nicht um die Freigabe kümmern.

    Michael

  • Original von Michael
    Original von Diskordia
    Ein String welcher mit @"asdf" erzeugt wird, liegt, wie alle Basistypen (int, douple, etc.) auf dem CP Stack und nicht auf dem Heap

    Das ist so nicht richtig. Ob etwas auf dem Stack oder Heap erzeugt wird, hängt nicht vom Datentyp ab. Stell Dir mal ein Objekt vor, welches einen int oder double als Instanzvariablen hat. Diese Instanzvariablen kommen nicht auf den Stack.

    Auf dem Stack landen lokale Variablen, Parameter von Funktionen, etc. Also Sachen, die nur einen definieren Lebenszeitraum und Speicherplatzbedarf haben. Der Compiler generiert dann entsprechenden Code, der den Speicher auf dem Stack reserviert und auch wieder frei gibt. Stichwort: automatische Variablen.

    Der Heap ist der großen Haufen Speicher, der vom System verwaltet wird. Will ein Programm dort Daten ablegen, muss es vom System eine entsprechende Portion Speicher anfordern. Das passiert auch beim Erzeugen von Objektive-C Objekten durch die Methode +alloc. Deshalb landen alle Objective-C Objekte auf dem Heap.


    Stimmt, hätte ich genauer bechreiben können.
    Original von Michael

    Dann gibt es aber noch String-Konstanten, wie "ein C-String" oder eben auch @"NSString". Der Speicher für diese String-Konstanten reserviert auch bereits der Compiler, aber nicht auf dem Stack, sondern im Bereich des Programms selbst. Diese String-Konstanten sind also ab Start des Programms permanent bis zum Beenden des Programms im Speicher vorhanden.

    Und nochmal Grundsätzlich zu der Frage, warum man eine NSString Konstante (@"blablubb") nicht releasen muss. Die Regel ist ja einfach: Objekte, die man mit alloc, new, copy oder mutableCopy erzeugt, muss man auch releasen. So, hat man nun bei der "Erzeugung" einer NSString-Konstanze eine dieser vier Methoden benutzt? Antwort: nein. Also muss ich mich auch nicht um die Freigabe kümmern.

    Michael

    Klar die Konstante muss im Programmspeicher vorhanden sein, sonst kennt die Applikation the Wert gar nicht, aber im Moment wo diese Konstante in der Methode gebraucht wird, wird ja ein NSString Objekt benötigt und eben dieses Object müsste doch auf dem Stack liegen?
    Ialea iacta est

  • Original von Diskordia
    Klar die Konstante muss im Programmspeicher vorhanden sein, sonst kennt die Applikation the Wert gar nicht, aber im Moment wo diese Konstante in der Methode gebraucht wird, wird ja ein NSString Objekt benötigt und eben dieses Object müsste doch auf dem Stack liegen?

    Das Objekt selbst bleibt wo es ist. Auf den Stack kommt dann nur der Zeiger auf das Objekt.

    Michael

  • Original von maultasche
    Und woher weiß ich das alles, was ich selber machen muß und was nicht?
    Der Nib-Loader lädt eine Datei. Wie kommst du auf den Gedanken, dass du das selbst machen musst? Dann wäre derNib-Loader ja kein Nib-Loader, sondern ein Nicht-Loader.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Ich komme deshalb darauf, weil ich nicht weiß das es einen NIB Loader gibt und auch nicht weiß was der macht. Mir ist halt noch a bisserl unklar, welche Objekte ich selber "allocen" muß, und welche eben automatisch erzeugt, bzw. verwaltet werden.

    Jens