• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"


  • Subject: Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"
  • From: Uli Kusterer <email@hidden>
  • Date: Sat, 4 Apr 2009 12:15:27 +0200

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 (email@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"
      • From: Michael Ash <email@hidden>
References: 
 >NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey" (From: Memo Akten <email@hidden>)
 >Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey" (From: Nate Weaver <email@hidden>)
 >Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey" (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"
  • Next by Date: Re: IB Plugin help
  • Previous by thread: Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"
  • Next by thread: Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"
  • Index(es):
    • Date
    • Thread