{"id":658,"date":"2010-07-19T23:56:19","date_gmt":"2010-07-20T04:56:19","guid":{"rendered":"http:\/\/vgable.com\/blog\/?p=658"},"modified":"2011-11-29T17:20:23","modified_gmt":"2011-11-29T22:20:23","slug":"define-string","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2010\/07\/19\/define-string\/","title":{"rendered":"#define String"},"content":{"rendered":"

When I need a string-constant, I #define<\/code> it, instead of doing the “right” thing and using an extern const NSString *<\/code> variable.<\/p>\n

UPDATE 2010-07-20<\/H3> Thanks to Elfred Pagen<\/a> for pointing out that you should always put () around your macros<\/strong>. Wrong: #define A_STRING @\"hello\"<\/code><\/del><\/p>\n

instead use (), even when you don’t think you have to:<\/p>\n

#define A_STRING (@\"hello\")<\/code><\/p>\n

This prevents accidental string concatenation<\/strong>. In C, string-literals separated only by whitespace are implicitly concatenated. It’s the same with Objective-C string literals. This feature lets you break long strings up into several lines, so NSString *x = @\"A long string!\"<\/code> can be rewritten:<\/p>\n

\n
\r\nNSString *x =\r\n\t@\"A long\"\r\n\t@\" string!\";\r\n<\/pre>\n<\/div>\n
Unfortunately, this seldom-used feature can backfire in unexpected ways. Consider making an array of two strings:<\/p>\n
\n
\r\n#define X @\"ex\"\r\n#define P @\"plain\"\r\na = [NSArray arrayWithObjects:X\r\n                              P,\r\n                              nil];\r\n<\/pre>\n<\/div>\n
That looks<\/em> right, but I forgot a “,<\/code>” after X<\/code>, so after string-concatenation, a<\/code> is ['explain']<\/code>, not ['ex','plain']<\/code>.<\/p>\n
Moral of the story: you can never have too many ()’s in macros<\/strong>.<\/p>\n
And, now, back to why I use #define<\/code>…<\/p>\n
It’s less code<\/h3>\n
Using an extern<\/code> variable means declaring it in a header, and<\/em> defining it in some implementation file. But a macro is just one line in a header.<\/p>\n
It’s faster to lookup<\/h3>\n
Because there’s only the definition of a macro, Open Quickly\/command-double-clicking a macro always<\/em> jumps to the definition, so you can see what it’s value is in one step. Generally Xcode jumps to a symbol’s declaration first, and then<\/em> it’s definition, making it slower to lookup the value of a const<\/code> symbol.<\/p>\n
It’s still type safe<\/h3>\n
An @\"NSString literal\"<\/code> has type information, so mistakes like,<\/p>\n
#define X (@\"immutable string\")\r\nNSMutableString *y = X;\r\n[y appendString:@\"z\"];\r\n<\/pre>\n
still generate warnings.<\/p>\n
It lets the compiler check format-strings<\/a><\/h3>\n
Xcode can catch errors like “[NSString stringWithFormat:@\"reading garbage since there's no argument: %s\"]<\/code>“, if you let it<\/a>. Unfortunately, the Objective-C compiler isn’t smart enough to check [NSString stringWithFormat:externConstString,x,y,z];<\/code> because it doesn’t know what an extern<\/code> variable contains until link-time. But preprocessor macros are evaluated early enough in the build process that that the compiler can check their values.<\/p>\n
It can’t be changed at runtime<\/h3>\n
It’s possible to change the value of const<\/code> variables through pointers, like so:<\/p>\n
\n
\r\nconst NSString* const s = @\"initial\";\r\nNSString **hack = &s;\r\n*hack = @\"changed!\";\r\nNSLog(s);\/\/prints \"changed!\"\r\n<\/pre>\n<\/div>\n
Yes this is pathological code, but I’ve seen it happen (I’m looking at you AddressBook.framework<\/code>!)<\/p>\n
Of course, you can re-#define<\/code> a preprocessor-symbol, so macros aren’t a panacea for pathological constant-changing code. (Nothing is!) But they push the pathology into compile time, and common wisdom is that it’s easier to debug compile-time problems, so that’s a Good Thing. You may disagree there<\/a>, and you may be right! All I can say for sure is that in my experience<\/em>, I’ve had bugs from const<\/code> values changing at runtime, but no bugs from re-#define<\/code>-ed constants (yet).<\/p>\n
Conclusion<\/h3>\n
Preprocessor macros are damnably dangerous in C. Generally you should avoid them. But for NSString*<\/code> constants in applications, I think they’re easier, and arguably less error prone. So go ahead and #define YOUR_STRING_CONSTANTS (@\"like this\")<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"
When I need a string-constant, I #define it, instead of doing the “right” thing and using an extern const NSString * variable. UPDATE 2010-07-20 Thanks to Elfred Pagen for pointing out that you should always put () around your macros. Wrong: #define A_STRING @”hello” instead use (), even when you don’t think you have to: […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18,6,203,3,5,4],"tags":[241,613,607,80,78,242],"class_list":["post-658","post","type-post","status-publish","format-standard","hentry","category-bug-bite","category-cocoa","category-iphone","category-macosx","category-objective-c","category-programming","tag-best-practices","tag-c","tag-constants","tag-macros","tag-nsstring","tag-programming-style"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/658","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=658"}],"version-history":[{"count":4,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/658\/revisions"}],"predecessor-version":[{"id":696,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/658\/revisions\/696"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=658"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=658"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=658"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}