Re: Accessor macros used by GNUstep but not Cocoa?
Re: Accessor macros used by GNUstep but not Cocoa?
- Subject: Re: Accessor macros used by GNUstep but not Cocoa?
- From: Bob Ippolito <email@hidden>
- Date: Fri, 28 Oct 2005 18:19:20 -0700
You're looking at it the wrong way.. it has nothing to do with macro
definitions.. any identical constant string in the code is going to
end up as the same pointer, and a @"literal" in the code has a
constant string backing. @"asdf" in your code is NOT equivalent to
[NSString stringWithCString:"asdf"] -- there is no such overhead (and
@"literals" are immortal like any other constant).
static definitions in separate source files produce separate
instances too. The cases where you do end up with the same instance
across compilation units is if you're getting them from an extern.
In any case, it really shouldn't matter because it's not semantically
valid to compare NSString instances by their pointer anyway. Whether
they're separate instances or not, your code should work, or else
your code is broken.
For some particular uses it might speed things up if they are the
same pointer (because the equality method can take a short-cut due to
identity), but these sorts of things are unlikely to get used often
enough to make that optimization is worth worrying about.
-bob
On Oct 28, 2005, at 6:45 AM, Daniel Jalkut wrote:
Interesting! I didn't know the compiler was smart enough to prevent
the macro definition from instancing into a separate NSString at
every use. In fact, I had a hard time believing it, so I ran the
following test (method infrastructure removed):
#define kMacroString @"Test1"
const NSString* kConstantString = @"Test2";
NSString* var1 = kMacroString;
NSString* var2 = kMacroString;
NSString* var3 = kConstantString;
NSString* var4 = kConstantString;
NSLog(@"We have four string vars: %@ (0x%x), %@ (0x%x), %@ (0x%x), %
@ (0x%x)",
var1, (void *)var1, var2,
(void*) var2,
var3, (void *)var3, var4,
(void*) var4);
-> We have four string vars: Test1 (0x4d894), Test1 (0x4d894),
Test2 (0x4d884), Test2 (0x4d884)
However, I would argue that it's still a good idea to use NSString
declarations for all of your globals, since it will make the
declarations consistent with those you decide to take global. Macro
definitions included to separate source files do produce separate
NSString instances.
Daniel
On Oct 27, 2005, at 8:03 PM, Bob Ippolito wrote:
Having constant NSString objects at file scope shouldn't really do
you anything useful.. all of the strings should end up in a
constant string table in a single compilation unit, so #define and
static NSString* should have the same net effect. If you are
doing it at file scope, you're just making the same optimization
that the compiler is doing anyway and might even end up making it
worse (though probably not measurably).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden