> Do not look at the retain counts. Down that path lies madness. > Frankly, -retainCount should be removed (or, better, modified to just > return rand()).
I wonder if the documentation should be updated with an explicit warning: --- Because any number of framework objects may have retained an object in order to hold references to it, while at the same time any number of autorelease pools may be holding any number of deferred releases on an object, it is very unlikely that you can get useful information from retainCount. If you think you can look at the value of retainCount in order to help debug a memory problem, then you probably do not understand Cocoa memory management well enough to debug the problem and will only confuse yourself further--in that case you should review <http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Memory Mgmt.html> and/or ask for help on the cocoa-dev mailing list. --- Now I phrase things very carefully in that, because I have in the past found it helpful to override retain, release, & autorelase in order to set breakpoints and see all the memory management actions on an object. In theory one should not have to do that. In theory one should just understand and follow the rules. But I had a weird failure to follow the rules which I was having trouble locating. (And of course, there is the very occasional framework bug as well.) So it's not altogether true that one should never snoop into retain/release, just that watching retainCount is a nearly completely useless way to do it. -- Scott Ribe [email protected] http://www.killerbytes.com/ (303) 722-0567 voice _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
