was spricht gegen autoreleasepools?

Die frage ist, was das für objekte sind, wofür sie gedacht werden, wie oft du sie nutzt und ob nicht sowieso ein manager viel schlauer wäre...

Das Delegate wird nicht viel bringen, weil das zu zerstörende Objekt zum Zeitpunkt des release ja immer noch im Call Stack hängt. Ich wüßte nicht, wo da der Vorteil sein sollte - es sei denn, Du rufst es per -performSelector:withObject:afterDelay: o.ä. auf. Aber das ist doch großer Heckmeck - Chartus hat Recht, genau für sowas ist autorelease da.

Andererseits: Was spricht gegen ein [self release], wenn Du danach nicht mehr auf die Membervariablen des zerstörten Objektes zugreifst? Die Methode selbst wird ja nicht zerstört, nur das Objekt, also der Speicher für den Zustand der Instanz.

Bei [self release] solltest dir bloß darüber im klaren sein, dass danach dein Objekt nicht mehr existiert, also noch in der Methode in der du dich befindest: Igitt.

Besser: [self autorelease], was dann ziemlich problemlos ist.

Na,, man weiß nie so genau woher man kommt. Gut gekapselt ist anders. Da bietet sich ein [self autorelease] an. (Habe ich auch schon bei "Download-Threads" gemacht, die ihre Daten ins Model stopften und sich dann verabschiedeten.)

Übrigens beseitigt ein -autorelease anstelle eines -release so manches Problem, was einem Kopfzerbrechen bereiten könnte. Das muss man immer im Hinterkopf behalten.

Instanzen dieses Subclasses erledigen völlig autonom in einer Art seperatem Thread eine Aufgabe.

Was heisst "eine Art"? Wenn Du einen richtigen 'thread' hast, ist auch ein extra AR vorhanden, und dann hast Du jede Kontrolle, die Du brauchst, also:

Endgültig verschwindet dann das Objekt, wenn der AR seinen Geist aushaucht.

Na, nur gut, dass da noch einer drauf gekommen ist. Sonst wäre das noch übersehen worden.

Original von Objcler
Okay - ich machs konkret:

Warum machst Du das nicht gleich.
Dann würde ich wirklich die Delegate-Methode animationDidEnd: verwenden.

Michael

Das wäre deutlich zu einfach gewesen, oder? *g*

Na ja, ich gehe jetzt davon aus, dass Michael die Fremdzerstörung als einfachere Alternative meinte.

Es gibt ja wirklich Fälle, da man eine Selbstzerstörung haben möchte -- aus Bequemlichkeit.

Original von Objcler

Ähm - welche Informationen hat dir mein letzter Post gegeben, die du zuvor nicht hattest und die dir geholfen haben deinen Lösungsvorschlag zu formulieren?

Da sind schon Unterschiede. 'NSAnimation' ist eine besondere Klasse, im Übrigen auch recht neu, die unter einer Option einen eigenen 'thread' startet, und beendet. Wie es darin aussieht, wer weiss das schon?
Der allgemeine Fall sieht das nicht vor, entweder "release" oder "autorelease", und dann :"Wo ist mein AR?", oder zentral und per 'delegate'. Die Antworten hast Du bekommen.
Ob das bei 'NSAnimation' sinnvoll ist, hängt nur davon ab, sollen die Objekte die Laufzeit der Animation überleben, oder nicht.
Wenn, dann nähme ich einen Container in einer Unterklasse von 'NSAnimation', und hoffte darauf, dass Apple die Objekte der Animation schon im richtigen 'thread' anwendet. So scheint es mir gedacht zu sein.

Original von Objcler
Ähm - welche Informationen hat dir mein letzter Post gegeben, die du zuvor nicht hattest

Dass Du den Thread nicht selbst startest.

Michael

Ruhig Blut!

Mit deiner eigentlichen Frage hatte es nichts zu tun, da die einfach auf ein selbstzerstörendes Objekt lautete. Und dafür ist es ziemlich gleichgültig, ob das in einem eigenen Thread hängt oder nicht. Es ist auch für den ARP gleichgültig, da man sicher einen solchen in Place hat. Sonst würde man nämlich keine drei Zeilen weit kommen.

Daher spielt es keine Rolle, ob du einen eigene Thread, mit einem eigenen ARP hast, keinen eigenen Thread mit einem eigenen ARP oder keinen eigenen Thread mit keinem eigenen ARP. Alles irrelevant.

Deshalb verlief die Diskussion auch ohne diese Information sinnvoll.

Es ist aber für den dahinter stehenden Zweck zumindest erläuternd, da man in der Tat *anstelle* der Selbstzerstörung an eine Fremdzerstörung in dem Delegate denken kann. Das hattest du aber genau genommen nicht gefragt, es war aber ein nützlicher Hinweis.

EBEN