I want to know the reference count of an object in my program. Can I?
Asked
Active
Viewed 420 times
0
-
1If you follow apple's memory management guidelines you will never need to use reference count – Felipe Sabino Sep 20 '11 at 20:12
-
2Incidentally, to further back the over-zealous down voter... the apple documentation on retainCount states as follows... "Important: This method is typically of no value in debugging memory management issues. Because any number of framework objects may have retained an object in order to hold references to it, while at the same time autorelease pools may be holding any number of deferred releases on an object, it is very unlikely that you can get useful information from this method." – Simon Sep 20 '11 at 20:17
-
1possible duplicate of [How to get the reference count of an NSObject?](http://stackoverflow.com/questions/2640568/how-to-get-the-reference-count-of-an-nsobject) – jscs Sep 22 '11 at 06:18
6 Answers
6
Sure:
int referenceCount = rand();
The real answer, of course, is the retainCount method; NSUInteger rC = [someObject retainCount];. However, the value returned by it is useless.
never never use the retain count in a conditional
the retain count can never be zero
the retain count never reflects whether or not the object is autoreleased
a retain count of 2-bazillion is perfectly reasonable for some classes some of the time
the retain count for any object that passes through system API may be a seemingly random value within indicating a problem
Bottom line: If you treat the retain count as an absolute value, you are doing it wrong. You either increase or decrease the retain count through your code, Keep your plusses and minuses in balance, and you are doing it right.
bbum
- 162,346
- 23
- 271
- 359
1
Isn't it meant to be...
[obj retainCount];
Simon
- 8,981
- 2
- 26
- 32
-
I should also add that using retainCount for anything other than trivial debugging is not great - an object can remain for X amount of time even after it's retain count has dropped to zero. – Simon Sep 20 '11 at 20:09
-
1Even for trivial debugging it is usually more than worthless, it cause spending time chasing dead ends. See the @CocoaFo link for how to see retains, etc. – zaph Sep 20 '11 at 20:13
-
2Totally ridiculous down voting. He asked a specific question and was given a specific answer. He didn't ask whether it was good practice or not. – Simon Sep 20 '11 at 20:14
-
1
Never use retainCount, it does not work the way you think it does.
-
1So how does it work, or why doesn't it work the way he thinks it does? – Rudy Velthuis Sep 20 '11 at 20:25
-
Mainly it is a problem because it does not take into account the retains/autoreleases that the frameworks do. Additionally it never goes to zero. Th problems are not limited to these preceding, for more information search SO. If one really wants information on the retain history of an object there is a great tool: Allocations in Instruments. – zaph Sep 20 '11 at 20:29
-
How do you know what he thinks it does? Or others who may read this question later? If you *really know* how it works it can be useful to look at when debugging something that isn't dealloc'd when you think it should've been. – progrmr Sep 20 '11 at 22:09
-
@progrmr: Indeed. Checking the value of retainCount can be useful. And, as I said before, it "works" exactly the way I think it "does" and "should do". – Rudy Velthuis Sep 21 '11 at 00:33
1
As everybody said, you can, BUT DON'T USE IT.
Back when I started I also thought that using the ref count I could find my memory problems easier. I wasted TOO MUCH time. The number you get is simply wrong in the sense that you can not (easily) just use it to find your memory management issues.
It is by far better to really check all the manually created objects with alloc, new, and your manual retains.
Simply sit back and focus onthe question "Who has ownership of this variable?" All thouse will keep your var alive. Also be sure to set your ivars with self.ivar, otherwise the ownership to the object will not be set.
But the easiest is to just use ARC in the newest version. This takes care of (most) of all these questions....
user387184
- 10,953
- 12
- 77
- 147
1
Not sure why all the posts about not using retainCount, its been valuable in tracking down memory issues for me, now I wouldn't use it as a conditional, nor even understand how that would even be used, but you can add a simple category and use retain count adequately to determine lifetime usage of any given class.
@implementation replaceWithYourClassName (MemoryInspecting)
- (id) retain
{
NSLog(@"RETAIN: self [%@] : retain count [%d]", [self description], [self retainCount]);
return [super retain];
}
- (void) release
{
NSLog(@"RELEASE: self [%@] : retain count [%d]", [self description], [self retainCount]);
[super release];
}
And throw some breakpoints in there to track the context if that helps, as it often does.
EricLeaf
- 892
- 5
- 12
-
1You don't need to do `[self description]` when using `NSLog` -- it's done automatically. – jscs Sep 20 '11 at 21:42
-
3This is the one pattern where rC is almost useful, but generally it is easier to just use the Allocations instrument and Malloc Stack logging. Note that the rC isn't particularly useful in this case, even, in that you are looking for matching events. Note also that the autorelease pool is going to arbitrarily delay the releases. – bbum Sep 20 '11 at 21:51
-
I don't know what NSLog you are using but [self description] does not get output with the standard NSLog. – EricLeaf Sep 20 '11 at 22:06
-
2
-
1@EricLeaf: see [Format Specifiers](http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html%23//apple_ref/doc/uid/TP40004265) -- `%@` causes `description` to be sent to the object. – jscs Sep 20 '11 at 22:36
-