Re: Status of @"" strings
Re: Status of @"" strings
- Subject: Re: Status of @"" strings
- From: Fritz Anderson <email@hidden>
- Date: Thu, 12 Jul 2001 14:12:07 -0500
At 10:46 AM -0700 7/12/2001, Chris Kane wrote:
On Thursday, July 12, 2001, at 12:56 AM, Art Isbell wrote:
These are uniqued string constants, probably similar to C
string constants (someone more familiar than I with string
constants please correct me).
Careful: these are NOT uniqued. At least, not globally in the app,
which is what most people might expect from being called "uniqued".
They are only uniqued within a translation unit to the compiler, and
that because of a happy-accident of implementation.
Can we explore this a little further?
The Cocoa frameworks make frequent use of NSStrings to provide
identifiers for things like standard NSDictionary keys -- serving
much the same purpose as 'symbols would in LISP, or #symbols in
Smalltalk, or interned java.lang.Strings. In those languages (if
memory serves), the address of the string sufficed to identify the
symbol; that is, you could do numeric comparisons on address-sized
integers without having to resort to a lexical comparison of the
characters. In yet other words, you could say
const NSString * MYSymbolString = @"MYSymbolString";
...
if (inSymbol == MYSymbolString)
instead of
if ([inSymbol isEqualToString: MYSymbolString])
... which at least incurs the overhead of a message send, and if
isEqualToString: is implemented naovely (by not checking for identity
of self and parameter), is more expensive still.
So, a question.
If one is looking for a framework-defined symbol (e.g.,
NSFontAttributeName), is it safe to rely solely on the equality of
the object addresses? From what you say, I am guessing no, because
(a) even if the two symbol references originated in the same
application, it's only a "happy accident" that the two references
should be to the same object; (b) symbols loaded at runtime, such as
from decoded NSDictionaries, don't get interned; and (c) there's
always some smartaleck who writes @"NSFontAttributeName" instead of
NSFontAttributeName.
Am I with you?
-- F