Nate Weaver wrote:
IIRC they're optimized to point to the same memory location (I wasn't sure, so I tested and confirmed).
Well, within a particular Mach-O Container, yes. But if you have a framework and an application, they could presumably get two different strings (It's an implementation detail I wouldn't rely on if constants are merged across containers). So if you're intending to compare them using == and not using -isEqualToString:, a #define will not do.
On 04.04.2009, at 00:44, Quincey Morris wrote:
Except that the reason for *that* is to have the names of the strings in the public API but to keep the content of the strings out of it, which is presumably not a consideration for the OP.
Exactly. It's not just so Apple are able to hide the string from you (you could use NSLog to easily print the contents, after all), but also to be able to change the actual value at any time, e.g. if they notice a common namespace collision etc.
I'd choose the #define version, and give the compiler elbow room to do its job of optimizing away duplicate literals -- and whatever else it can do, such as possibly putting string literals in read- only address space.
It will do all of this for the string literal being assigned to your global kMyKey variable as well. It's just that the actual kMyKey is still there, pointing at the string.
But the difference (if any) between the two approaches is so minimal that personal preference is a fine criterion for deciding. :)
If you're inside a single, monolithic application, yes. However, #define is eliminated by the preprocessor, whereas kMyKey would still be exported to the linker, e.g. in the case of a framework. Which means you can make 100% sure that this one key string is shared by anyone in the current address space ("linked into the application") who is using your framework. That in turn means you can compare the actual address of the string, without having to look at its contents.
Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
