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: Sat, 29 Oct 2005 01:30:31 -0400
I think you're right that ultimately it doesn't matter, but a
constant @"" string defined in a header file will be instantiated
separately for each source file that includes it.
For the obsessive compulsives in the audience, maybe it will feel
better to know that the string constant is restricted to 1 instance
instead of, say, 5 instances, in the various project source files
it's referenced in. <Raises Hand> :)
Daniel
On Oct 28, 2005, at 9:19 PM, Bob Ippolito wrote:
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