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 (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
