> The most complex change is the move from -dealloc to > -finalize. Finalizers are executed in an effectively > random order whereas many people seem to want deallocs to > be executed in a fixed, dependent, order.
> In reality, incurring order dependencies on -dealloc is a really bad > idea; one unexpected -retain [leak] or -autorelease [order change] > and the house of cards falls over (this has been a *huge* debugging > time sink, in my experience). Finalizers force the issue by making > ordered execution nearly impossible to achieve. Yes, I agree with that (just got bitten by that one in fact). In the world I am used to, destructors get called in a deterministic fashion (which I like), but even in autorelease world you can't rely on that. For example, when an NSWindow is release-on-closed, it gets dealloc'd, I just discovered, *before* the NSViews it contains. This strikes me as dangerous actually, as the NSViews might feel they are entitled to refer to the NSWindow in which they reside until they are deallocated, but that seems to be the way it works. > Of course, you could choose to go down the route of using the various > APIs to allocated collectable/scanned memory while using __strong and > __weak to make the non-ObjC code more GC friendly. There will be an > ever growing performance gain to be had in doing so, but it is very > hard to get right. (The ObjC garbage collector is not actually an > ObjC garbage collector -- it is entirely language agnostic. The > "ObjC" part is that it is fully automatic with Objective-C, but must > be manually integrated with everything else.) Judging by a recent thread on this topic, it sounds safer to manage 'legacy' mallocs / new's yourself. I personally wouldn't want the garbage collector to interfere with this. But I haven't read the docs so I don't know what the garbage collector brings to the party. > The bugs at the border will typically be premature destruction of memory. Ouch! Sounds like the key thing is a thorough understanding of how it works. I think ought to add that I am not using GC primarily because I want my code to run on Tiger. I can see that it will be a big win for many Cocoa programmers. (Off topic again): Call me old-fashioned, but I don't like autorelease pools all that much. I believe Cocoa could have gotten along just fine without them, had they never been invented. I prefer C++-style 'smart pointers' that delete (or release) themselves when they go out of scope. That way you avoid the loss of determinism and potential memory usage peaks that autorelease pools introduce and it's really not painful writing code that way. It's a pity that Objective-C doesn't support such a construct - life would have been so much easier. But it's far too late now. Rgds - Paul Sanders. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
