I guess this just proves the age-old rule, "never rely on the return
value of -retainCount to make sense." :)
Seriously, this does seem weird, but -retainCount seems to have a mind
of its own. Just have faith in the memory management rules.
Brian Greenstone wrote:
I'm hoping someone can shed some light on this for me. I'm getting
some unusual retainCount values from the following code:
NSTimer *theTimer;
theTimer = [NSTimer scheduledTimerWithTimeInterval:1.0
target: self
selector: @selector(timerCallback)
userInfo: nil
repeats: YES];
NSLog(@"A: retain count: %i", [theTimer retainCount]);
[[NSRunLoop currentRunLoop] addTimer: theTimer forMode:
NSDefaultRunLoopMode];
NSLog(@"B: retain count: %i", [theTimer retainCount]);
The output I get is:
A: retain count: 2
B: retain count: 2
But that shouldn't be, right? Shouldn't the retainCount of theTimer
be 1 after scheduledTimerWithTimeInterval? Then shouldn't it be
bumped up to 2 after adding the timer to the Run Loop? It appears
that the retain count is starting at 2 which is wrong, and then not
being incremented by addtimer which is wrong. In the end the count is
still 2, so it is valid, but I'm confused why the counts are doing this.
Thanks,
-Brian
_______________________________________________
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/jstiles%40blizzard.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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]
