On Oct 22, 2008, at 12:54 PM, Marco Masser wrote:
I don't know of any way to look into an autorelease pool, if you mean that : )I just made an NSColor ivar and retained it after calling - getColor:location:atIndex: and took a look on its retain count in a second method that was called after the NSAutoreleasePool had been drained (i.e. I took a look at the retain count after pressing a button). That way, all -autorelease messages must have been dealt with. In the second method, the count was 2. After removing the - retain following the -getColor..., the retain count in the second method was 1.
In general, the retain count is entirely meaningless. The retain count of any given object, especially objects that were created by or have passed through the Apple provided frameworks, may be seemingly random due to the internal implementation details of the class or of the frameworks. Caching, singletons, and any of a number of optimizations could impact the retain count.
Frankly, -retainCount should be deprecated and eliminated.If you are trying to find a leak, then use one of the tools on the system designed for exactly that -- leaks, Object Graph in Instruments for GC, Object Alloc for non-GC, etc...
Now... in this particular case...How can you look at the retain count of an object after the autorelease pool was drained without it being retained by something? Didn't you have to retain it to keep the NSColor iVar around?
b.bum
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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 [EMAIL PROTECTED]
