the previous response to Bill is relevant to this response.
ok. What percentage of cocoa classes will exhibit the behavior you describe? I've never seen an objc class that mysteriously hangs around beyond the destruction of its dependencies (including any autorelease pools that contain it). I wouldn't be shocked if there were some....maybe some system singletons? If 90% of objc classes are completely deterministic in their life cycle behavior with retain/release and 10% aren't, I'll not use the 10% to make the case that I should introduce even more entropy into my system by using garbage collection. GC isn't nirvana. it does have its perils and issues, and you have to be aware of them and code around them. You can't just turn it on and some how everything magically works. There is no perfect solution to memory management. I prefer a solution where I manage the dependencies and objects go away in an orderly fashion based on the dependency graph for those objects. additionally, I find the notion of adding an extra subsystem that periodically scans memory looking for pointers to be foolhardy. my code already knows what needs to be cleaned up and when. I don't need a system sitting in the background scanning memory trying to clean up behind me. All I need is a mechanism to do the cleanup in a maintainable and extensible manner. I'm just expressing my personal opinion. I realize GC has its fans who will disagree. Personally, think GC should have been left in the realm of scripting languages where it belongs. HOWEVER, I will admit that I don't know if the cocoa runtime could be retrofitted to use smart pointers without breaking compatibility. So, maybe there was no other choice in fixing the perils of manual memory management in objc....I'd buy that statement if it was made. On Friday, June 26, 2009, at 02:52PM, "Michael Ash" <michael....@gmail.com> wrote: >On Fri, Jun 26, 2009 at 2:31 PM, James Gregurich<bayoubenga...@mac.com> wrote: >> >> If my resource is handed off to some external subsystem for release and I >> can't DETERMINE the order of the releases with respect to each other and >> other components of my code, then I would call that non-deterministic and >> undesirable. > >If nondeterministic memory deallocation is a dealbreaker for you, then >Cocoa is not for you, pure and simple. > >You cannot predict when your objects will be destroyed in Cocoa. >Garbage collection is irrelevant to this fact, and changes nothing >about it except the degree. > >Even a simple alloc/init/release pair is not guaranteed to destroy the >object on the release. The init method could store a strong reference >away somewhere, or do a retain/autorelease combo, or pass a reference >off to another thread, and now you're screwed. > >All GC does is make it happen more often. You *never* could rely on >object lifetimes. If your non-GC code relies on precisely controlling >object lifetimes, then you have a bug, and should fix it. > >Mike >_______________________________________________ > >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/bayoubengalml%40mac.com > >This email sent to bayoubenga...@mac.com > > _______________________________________________ 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
