Re: NSString Retain Count of 2147483647
Re: NSString Retain Count of 2147483647
- Subject: Re: NSString Retain Count of 2147483647
- From: Clark Cox <email@hidden>
- Date: Wed, 24 Jun 2009 08:05:49 -0700
On Wed, Jun 24, 2009 at 7:58 AM, Gwynne Raskind<email@hidden> wrote:
> 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.
Too late, I've already answered ;)
> 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.
I can't second this advice enough. Anytime you're looking at the
retainCount directly, you're probably overthinking your issue.
> 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.)
In my experience, the edge-cases that you encounter when using GC, are
*much* rarer than the problems encountered when using retain/release.
Unless given a good reason not to (i.e. needing to support 10.4 or the
iPhone), I would *always* default to using GC on OS X. (and prior to
actually using it, I was deeply in the anti-GC camp).
--
Clark S. Cox III
email@hidden
_______________________________________________
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