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: Daniel Jalkut <email@hidden>
- Date: Fri, 28 Oct 2005 09:45:23 -0400
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