> If Apple later on wants to change how it works > internally so that the function returns a temporary object instead, > well, too bad, can't!
Well, that's patently untrue. It can just return a temporary object with a retain count of 1. It comes down to a simple question of whether or not you are happy to entask programmers to release objects - any object - when they are done with them. I personally feel a lot happier doing things that way as (a) I can get rid of things I don't want in timely fashion, and (b) I can test my program for memory leaks. Autorelease pools make the latter effectively impossible. It's no coincidence that a lot of programmers new (and perhaps not-so-new) to the Mac have object lifetime issues. I think it is a practical impossibility to prove your app is leak-free under Cocoa whereas on a certain other platform I can and do check if there is any memory left allocated at the end of the app (assuming everything is correctly released on shutdown). I really miss the ability to do that and I know for a fact that what I will end up shipping will have memory leaks, somewhere. _______________________________________________ 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
