Re: NSCalendarDate loses retain count [Solved confusion]
Re: NSCalendarDate loses retain count [Solved confusion]
- Subject: Re: NSCalendarDate loses retain count [Solved confusion]
- From: Kurt Revis <email@hidden>
- Date: Fri, 26 Oct 2001 18:17:17 -0700
I was looking inside the object in the debugger, and seeing the private
refCount member.
\Aha, that's what I suspected. I should have said so in the first place!
Generally, you are better off trying to solve problems using the public
interface (methods) of objects, rather than poking around in their
insides directly. You never really know what any private variables are
really used for--you can make an assumption (like you did in this case)
but more often than not you'll be wrong and just get more confused.
It is enticing to just poke around in the outline view of objects that
the debugger shows you, but very rarely useful. I almost never use
that--only on my own objects, when I know how they are implemented.
Instead, you can call any method you like from the gdb command line. For
example, in this case, you could say "p (unsigned int)[someDate
retainCount]" and get the real retain count. Or put in an NSLog.
After calling [[NSCalendarDate alloc] init] or [NSCalendarDate
calendarDate] it was zero, when calling retain it went from zero to 1.
When exiting the pool it went to zero. Calling retain twice on
retainedCalendarDate2 within the pool caused it to go to 2.
So this variable is related to the retain count, but isn't exactly the
same as the retain count. I don't know what exactly the relationship
is... and I don't care.
There is indeed another member called retainCount that every object
has, and after adding the logs can verify that it doesn't prematurely
fall to zero.
It's not a member (an instance variable)--all NSObjects have a *method*
which returns the retain count. From the outside, you can't tell exactly
where this retain count is kept. For NSCalendarDate, you found out that
it has something to do with the internal refCount variable; for other
classes it is done in different ways. If you use the public interface,
you don't have to worry about the internals.
--
Kurt Revis
email@hidden