When to use -retainCount?

You should never use -retainCount because it never tells you anything useful. The implementation of the Foundation and AppKit/UIKit frameworks is opaque; you don't know what's being retained, why it's being retained, who's retaining it, when it was retained, and so on.

You should never use -retainCount, because it never tells you anything useful. The implementation of the Foundation and AppKit/UIKit frameworks is opaque; you don't know what's being retained, why it's being retained, who's retaining it, when it was retained, and so on. For example: You'd think that NSNumber numberWithInt:1 would have a retainCount of 1.It doesn't.

It's 2. You'd think that @"Foo" would have a retainCount of 1.It doesn't. It's 1152921504606846975.

You'd think that NSString stringWithString:@"Foo" would have a retainCount of 1.It doesn't. Again, it's 1152921504606846975. Basically, since anything can retain an object (and therefore alter its retainCount), and since you don't have the source to most of the code that runs an application, an object's retainCount is meaningless.

If you're trying to track down why an object isn't getting deallocated, use the Leaks tool in Instruments. If you're trying to track down why an object was deallocated too soon, use the Zombies tool in Instruments. But don't use -retainCount.It's a truly worthless method.

Edit Please everyone go to http://bugreport.apple.com and request that -retainCount be deprecated. The more people that ask for it, the better.

1 Thanks @Dave-Delong for your examples. – Moszi Jan 11 '11 at 0:01 retainCount is currently useful for singletons.(Now the question is how useful are singletons...) - (NSUInteger)retainCount{return NSUIntegerMax;}. – Joe Mar 22 '11 at 13:05 3 @Joe you can make a singleton without overriding retainCount.

– Dave DeLong Mar 22 '11 at 14:12 One can also bake a cake without eggs. Apple recommends overriding the retainCount to ensure the status of the of the singleton in a non-garbage collecting environment. Developer.apple.com/library/mac/documentation/Cocoa/Conceptual/… – Joe Mar 22 '11 at 14:18 2 @Joe I'm aware of that; Google "objective-c singleton" for all the discussion on why that example isn't a very good one.

– Dave DeLong Mar 22 '11 at 16:42.

NEVER! Seriously. Just don't do it.

Just follow the Memory Management Guidelines and only release what you alloc, new or copy (or anything you called retain upon originally). @bbum said it best here on SO, and in even more detail on his blog.

– Moszi Jan 8 '11 at 21:10 4 Because you'll think you're counting memory, but you will be doing it wrong. – Abizern Jan 8 '11 at 21:12 2 To add to this, any information you could gain from -retainCount can be gotten (with much more detail) from Instruments and its tools. – Dave DeLong Jan 8 '11 at 21:45 2 To add to what Dave said; the absolute retain count of an object is an implementation detail.

Both a detail of the internals of the object and/or a detail of any other object the object may have been passed through. Calling retain, retain, retain, autorelease, autorelease, autorelease could be a perfectly valid result of passing an object through the UIKit API, for example. – bbum Jan 9 '11 at 0:25 2 @d11wtq If retainCount ever == 0, the singularity has been achieved!

– bbum Jan 9 '11 at 18:41.

Autoreleased objects are one case where checking -retainCount is uninformative and potentially misleading. The retain count tells you nothing about how many times -autorelease has been called on an object and therefore how many time it will be released when the current autorelease pool drains.

Thanks - this is a good point. This is the first answer which actually has a reason described why not use retainCount, besides the generic "don't". – Moszi Jan 8 '11 at 21:30 @Moszi: Your question was "When to use retainCount?" — if you didn't mean to ask that question, you should have asked something else.

– Chuck Jan 8 '11 at 22:06 @chuck - actually I was interested in "when to use it", however it seems that every answer is going to be "never" ... But - I guess you are right. I will leave the question open for a couple of days, and if there is going to be no answer other then never, then I will accept "never" as an answer. – Moszi Jan 8 '11 at 23:39.

I do find retainCounts very useful when checked using 'Instruments'. Using the 'allocations' tool, make sure 'Record reference counts' is turned on and you can go into any object and see its retainCount history. By pairing allocs and releases you can get a good picture of what is going on and often solve those difficult cases where something is not being released.

This has never let me down - including finding bugs in early beta releases of iOS.

Take a look at the Apple documentation on NSObject, it pretty much covers your question: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html%23//apple_ref/occ/intfm/NSObject/retainCount In short, retainCount is probably useless to you unless you've implemented your own reference counting system (and I can almost guarantee you won't have). In Apple's own words, retainCount is "typically of no value in debugging memory management issues".

First of all thank you for you answer. Usually peoples reaction to this question is "NEVER". (See the answers).

Actually "no value in debugging" doesn't mean "NEVER". So my question is – why is the strong feeling of not using it (for instance in singleton implementation - one of the answers again)? – Moszi Jan 8 '11 at 21:13 I guess you would need to provide more information about what you're using it for.An acceptable use would be, as suggested by Apple, overriding retainCount to implement your own reference counting system.

But in practice, you'd never see that (I never have, anyway). The strong reaction generally comes from the fact Apple themselves have advocated (in their mail groups, the docs, the dev forums, etc) to leave retainCount alone. – lxt Jan 8 '11 at 21:21 1 @Moszi: Debugging is the only situation in which most people could conceive of it having value, so if it is unreliable there, it is never useful.

What other uses are you thinking of? – Chuck Jan 8 '11 at 21:45.

You should not be worrying about memory leaking until your app is up and running and doing something useful. Once it is, fire up Instruments and use the app and see if memory leaks really happen. In most cases you created an object yourself (thus you own it) and forgot to release it after you were done.

Don't try and optimize your code as you are writing it, your guesses as to what may leak memory or take too long are often wrong when you actually use the app normally. Do try and write correct code e.g. If you create an object using alloc and such, then make sure you release it properly.

While these are generally good advices :) - they do not answer my question ... – Moszi Jan 8 '11 at 21:22.

All it does is return the retain count of the object. I have never called it and can't think of any reason that I would. I have overridden it in singletons to make sure they aren't deallocated though.

There is no reason to override it in the singleton case. There are no code paths in the Foundation/CoreFoundation that use retainCount for memory management. – bbum Jan 9 '11 at 0:23 Doesn't release use it to decide if it should call dealloc?

– ughoavgfhw Jan 9 '11 at 2:35 2 Nope; the internal implementation of retain/release/autorelease has deep roots in CoreFoundation and is really not at all what you might expect. Go grab the CoreFoundation source (it is available) and have a look. – bbum Jan 9 '11 at 18:42.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.