Re: NSString Retain Count of 2147483647
Re: NSString Retain Count of 2147483647
- Subject: Re: NSString Retain Count of 2147483647
- From: Gwynne Raskind <email@hidden>
- Date: Wed, 24 Jun 2009 10:58:39 -0400
On Jun 24, 2009, at 10:26 AM, Thomas Wetmore wrote:
I know you're not supposed to use retain counts when debugging
memory issues, but I have found it very (VERY) useful at times.
While looking at retain counts of NSStrings I have found an oddity
that I think I understand, but would like confirmation if possible.
When I use NSScanners to chop strings up, whenever I pull a one-
character string out of a scanner that string has a retain count of
2147483647 (2**32 - 1). My guess is that there are pre-allocated,
one-character strings for all (most?) characters that are given this
maximum possible value of a retain count, the digital equivalent of
infinity. Then these one-character strings can be released pretty
much to one's heart's content but never deallocated unless there is
an incredible bug, in which case I'm guessing that another such one-
character string would be allocated to replace it.
Can anyone confirm this suspicion?
It might be true, but I deeply hope that no one at Apple actually
answers this question. What you're talking about is an internal
implementation detail. You can't expect to rely on it for more than
five minutes at a time. If monitoring the retain count of an object is
the answer to your problems, then you're going about things completely
wrong. Autorelease pools and singleton objects, to name two examples,
make the use of retain counts in debugging a complete fallacy. As
someone else pointed out, you can NEVER assume that you can safely
over-release an object, even if you know it's a constant string or
something similar. That sort of thinking leads to one thing: Bugs. If
you can't wrap your mind around the right way to do retain/release
management, then consider moving to GC-only programming, where the
failure modes are a bit better suited to nonlinear problem solving.
Keep in mind that I'm a very NON-fan of GC, but that's because 1, I
understand retain/release management very well and have been
consistently successful with it, 2, GC has hidden pitfalls (like the
internal pointer problem) that frankly confuse the heck out of me, 3,
my style of coding tends to avoid retain cycles, and 4, I'm from the
old school of coding where you didn't even have reference counting,
just NewPtr/Handle and DisposePtr/Handle :). A lot of arguments have
been made in favor of GC and I suggest considering them carefully.
(See the cocoa-dev and objc-language archives for several recent
discussions.)
-- Gwynne
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden