I actually don;t agree that the system keeping NSFonts around to use them is non-deterministic. The system will get rid of them when it is done with them. that is a perfectly predictable activity. Maybe I don't know what all the machinery is doing or what all the input is that goes into the machinery, but a given set of circumstances will cause the same result each time.
However, when you have an extra background process controlling the system according to the set of rules you don't control, that is certainly a situation where events will be happening in different sequences no matter that input you feed in. that can cause problems you have to work around. Yes, I'm sure people can come up with an endless list of background processes that drive my app that I don't control. But, adding one more unknown to the list that I can do without quite easily isn't useful. my statement is that I'd rather use shared_ptr & weak_ptr. I'll know exactly what my system is doing in a way that is as predictable as possible yet is completely safe and reliable....and maintainable. On Friday, June 26, 2009, at 06:56PM, "Michael Ash" <michael....@gmail.com> wrote: >On Fri, Jun 26, 2009 at 8:40 PM, James Gregurich<bayoubenga...@mac.com> wrote: >> >> On Friday, June 26, 2009, at 04:41PM, "Kyle Sluder" <kyle.slu...@gmail.com> >> wrote: >> >>>100% might. Maybe 0% today, and then tomorrow Apple might release an >>>update that causes all objects to hang around forever. You don't >>>know, and you shouldn't care. >> >> I don't. in practice its not particularly relevant as I can't think of an >> instance where I made a class' lifecycle dependent on the lifetime of an >> NSFont (just to use your example). >> >> I really don't get this whole line of reasoning. I don't get why the fact >> that a system keeps an NSFont around justifies me adding a whole new system >> to scan memory and look for pointers to determine which ones need to be >> released. > >I think you've got it backwards. You're the one who said that GC was >bad because it has nondeterministic behavior for object destruction. >The rest of us are merely pointing out that Cocoa has nondeterministic >object destruction in non-GC mode as well. > >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
