• 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: Nate Weaver <email@hidden>
  • Date: Fri, 3 Apr 2009 18:28:49 -0500

I prefer the other for that exact reason since I don't have to have the actual definition in my headers, some of which (for notifications, e.g.) are used in a number of places.

From the Apple docs: "In general, don’t use the #define preprocessor command to create constants. For integer constants, use enumerations, and for floating point constants use the const qualifier, as described above." and "Define constants for strings used for such purposes as notification names and dictionary keys. By using string constants, you are ensuring that the compiler verifies the proper value is specified (that is, it performs spell checking). The Cocoa frameworks provide many examples of string constants [...]".

(http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html )

As for read-only address space, does the const declaration not take care of that? (Serious question.)

But, like Quincey said, it really shouldn't matter much!

On Apr 3, 2009, at 6:05 PM, Memo Akten wrote:

Thanks for the replies guys. I do prefer the #define method simply because it's less maintenance (only add to one header, instead of header + .m)

Cheers,

Memo.


On 3 Apr 2009, at 23:44, Quincey Morris wrote:

On Apr 3, 2009, at 15:15, Nate Weaver wrote:

IIRC they're optimized to point to the same memory location (I wasn't sure, so I tested and confirmed).

I usually do:

NSString * const kConstantNameHere = @"foo";

That's what I've seen in Apple headers (with an extern at the beginning and no assignment in said headers, of course).

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.


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.

But the difference (if any) between the two approaches is so minimal that personal preference is a fine criterion for deciding. :)
_______________________________________________

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


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>)
 >Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey" (From: Memo Akten <email@hidden>)

  • Prev by Date: Re: Non-pageable app
  • 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