Wenn man ein Release vergisst ist das erst dann "wirklich schlimm", wenn die Aktion in der das Objekt erzeugt wird, immer wieder ausgrführt wird, also immer mehr Speicher gebraucht wird. Dann wird der Computer auf Dauer natürlich auch langsamer.
Den Speicher "vollzukriegen" wirst du allerdings kaum schaffen Und von selbst wird sich dein Objekt nicht löschen.

Nimm einfach immer Autorelease, dann passiert auch nix.

Kann sein, dass ich deine Frage nicht verstanden hab…
Das bezieht sich alles auf die LAUFZEIT.

beim Beenden eines Programmes jedoch wird jedes Objekt aus dem Speicher gelöscht...
stimmt doch, oder?

lg
oddy

Original von oddysseey
beim Beenden eines Programmes jedoch wird jedes Objekt aus dem Speicher gelöscht...
stimmt doch, oder?

lg
oddy

Wenn nicht, wär schlecht

Original von læng
Den Speicher "vollzukriegen" wirst du allerdings kaum schaffen

Woher willst Du das wissen? Kommt auf das Objekt, die Häufigkeit der Erzeugung und der Laufzeit des Programms an. So ein fettes NSImage schafft da schon was weg. Und wenn der RAM voll ist, fängt das Swappen an und der Rechner wird richtig lahm.

Michael

Original von Michael

Original von læng
Den Speicher "vollzukriegen" wirst du allerdings kaum schaffen

Woher willst Du das wissen? Kommt auf das Objekt, die Häufigkeit der Erzeugung und der Laufzeit des Programms an. So ein fettes NSImage schafft da schon was weg. Und wenn der RAM voll ist, fängt das Swappen an und der Rechner wird richtig lahm.

Michael

Ja, klar. Also "der Speicher" != "der physikalische Speicher"

Original von Michael
So ein fettes NSImage schafft da schon was weg. Und wenn der RAM voll ist, fängt das Swappen an und der Rechner wird richtig lahm.
Michael

So wie bei Photoshop CS2, ok die machen das nicht mit NSImage ;-)) aber Speicher wird trotzdem nicht freigegeben, wenn die Bilder geschlossen werden. Da wird lieber munter geswappt...

Gruß
jerry

Original von længJa, klar. Also "der Speicher" != "der physikalische Speicher"

Ab 3GB ist Schicht im Schacht und OS X schmeißt das Programm aus dem Speicher, ganz einfach weil irgendwann der Adressraum für 32bitter ausgeht.

Könnt ihr jaj einfach testen (keine Ahnung ob der Code jetzt korrekt ist



Dann ist dein Speicher voll, nach gar nicht mal so langer Zeit.

Ja, es ist schlimm, wenn man ein release vergisst. Es ist schlicht ein Fehler. Objekte löschen sich, während das Programm läuft, nicht von selbst - wenn sie das könnten, bräuchte man das release gar nicht. Wenn der Prozess beeendet wird, wird allerdings der virtuelle Addressraum des Prozesses zerstört, womit auch alle allokierten Speicherbereiche weg sind - zumindest bei "normalem" Speicher, z.B. bei shared memory sieht das anders aus. So einige Ressourcen überleben ihr Prozessende zumindest teilweise.

Wenn es nur ein kleiner Speicherbereich ist und der betreffende Code nur einmalig oder sehr selten ausgeführt wird, führt das nicht unbedingt und immer zu einer Katastrophe, aber gerade das kann ziemlich fies werden. Code kann ziemlich lange in Revisionen überleben und per copy & paste in andere Projekte wandern - kurz: irgendwann mal an einer Stelle landen, für die er ursprünglich gar nicht gedacht war. Und dort zu fiesen Problemen führen, z.B. unregelmäßigen Abstürzen, die kaum noch zu finden, geschweige denn zu beheben sind.

Das mag alles arrogant, aber bei Speicher bin ich pingelig. Es gibt gute Ansätze, seinen Code übersichtlich zu halten, und so zu gestalten, dass es fast unmöglich wird, releases zu vergessen. Und es gibt gute Werkzeuge zum Testen von Speicheroperationen. Wer die kennt, ist klar im Vorteil.

Automatisch gelöscht wird es, wenn du ein -autorelease schickst. Deshalb heißt das Dingens ja so.

Du müllst den Speicher voll. Er bleibt bis zum Programmende reserviert. Das kann zu Swapping (Auslagerung von physikalischen Speicher auf die Festplatte) führen. Dies kostet kräftig Zeit.

a) Du benutzt gleich einen convenience Allocator. Der macht das für dich.b) Wenn du keinen hast, oder ihn aus Voodoo-Gründen nicht verwenden willst, machst du es halt selbst.

um das mal ganz kurz noch zu vervollständigen

autorelease heißt das Objekt verschwindet immer wenn der runloop durchgelaufen ist:

Faustregel: immer dann wenn alle deine eigenen Methoden durchlaufen sind und das Programm wieder auf eine benutzereingabe warten muß werden alle autoreleased Objekte freigegeben

soll dein objekt den runloop überleben mußt du es retainen

und vllt noch als Hinweis:

Container retainen und releasen ihren Inhalt selbst!

wenn du dich strikt daran hältst möglichst nur convenience allocators zu verwenden und alles was du brauchst in Standard Containern abzulegen hast du eine der größten Fehlerquellen schon mal ausgeschlossen

Objekte im Nib werden gar nicht von dir verwaltet. Darum kümmert siich der Nib-Loader.

Original von Tom9811
Objekte im Nib werden gar nicht von dir verwaltet. Darum kümmert siich der Nib-Loader.

Doch! Wenn ein Nib geladen wird, haben alle Top-Level-Objekte (also alle, die man im Instances-Inspector sieht) retain count 1. Sie müssen von einer externen Instanz released werden - darum kümmert sich der Nib Loader nicht. Oft ist es allerdings trotzdem nicht notwendig, sich darum zu kümmern, denn die Objekte im MainMenu-Nib leben normalerweise die ganze Laufzeit des Programms und bei Nibs, die von einem NSWindowController geladen werden, kümmert sich der WindowController um das Release des Fensters. Wenn man allerdings händisch ein Nib lädt, müssen die Top-Level-Objekte auch händisch released werden, typischerweise vom File's Owner.

Original von mattik
bei Nibs, die von einem NSWindowController geladen werden, kümmert sich der WindowController um das Release des Fensters.

Ergänzung: NSWindowController kümmert sich um alle Top-Level-Objekte.

Michael

Das macht dder Window-Controller selbst:

Freeing top-level objects when the window controller is deallocated
As the nib file’s owner, the window controller is responsible for freeing any top-level objects instantiated in the nib file. This includes the window itself and any additional objects you might have added to the nib file. The window controller automatically keeps track of these objects when it loads the nib file, and then releases them when the window controller is deallocated.

Übrigens auch dann, wenn er nicht Owner ist. Im obigen Text ist das zwar missverständlich. (Es wird einfach davon ausgegangen, dass der WC der Owner ist.) An anderer Stelle findet man aber einen ausdrücklichen Hinweis:

The relationship between a window controller and a nib file is important. Although a window controller can manage a programmatically created window, it usually manages a window in a nib file. The nib file can contain other top-level objects, including other windows, but the window controller’s responsibility is this primary window. The window controller is usually the owner of the nib file, even when it is part of a document-based application. Regardless of who is the file’s owner, the window controller is responsible for freeing all top-level objects in the nib file it loads.

Ich sehe also nicht, warum man damit etwas zu tun haben sollte, lasse mich aber gerne belehren. Wäre wichtig für mich.

+++
ARGH

Stand der Hinweis auf den WC von Anfang an in deinem Beitrag und ich habe ihn überlesen? Wie dem auch sei. Ich habe bisher nur so Nibs geladen.