When to use static string vs. #define

Question

I am a little confused as to when it's best to use:

static NSString *AppQuitGracefullyKey = @"AppQuitGracefully";

instead of

#define AppQuitGracefullyKey    @"AppQuitGracefully"

I've seen questions like this for C or C++, and I think what's different here is that this is specifically for Objective C, utilizing an object, and on a device like the iPhone, there may be stack, code space or memory issues that I don't yet grasp.

One usage would be:

appQuitGracefully =  [[NSUserDefaults standardUserDefaults] integerForKey: AppQuitGracefullyKey];

Or it is just a matter of style?

Thanks.

score 60 · Accepted Answer · answered Jan 19 '10 at 08:16

60

If you use a static, the compiler will embed exactly one copy of the string in your binary and just pass pointers to that string around, resulting in more compact binaries. If you use a #define, there will be a separate copy of the string stored in the source on each use. Constant string coalescing will handle many of the dups but you're making the linker work harder for no reason.

answered Jan 19 '10 at 08:16

cdespinosa

20,661
6
33
39

9

Constant string coalescing is the work of the compiler, not the linker. – kennytm Jan 19 '10 at 08:21
1

This is not right. Objective-c uses [String Interning](https://en.wikipedia.org/wiki/String_interning) as described [here](http://nshipster.com/equality/). `#define` does _not_ store a copy of the string for each use. And @kennytm is right, the compiler does that, not the linker – André Fratelli Jul 02 '15 at 12:07
2

@AndréFratelli In point of fact, constant string coalescing is a linker optimisation, and it is implemented by the static linker in OS X/macOS for both C and CF/NSStrings. It is not done using string interning, and it is not done by the compiler (though the compiler may coalesce strings itself before writing out the object file its generating). You can see the code that does this in [the linker sources](http://opensource.apple.com/source/ld64/ld64-264.3.102/). So no, kennytm is not right; it really is the linker. – al45tair Sep 22 '16 at 08:56
@alastair I guess it makes sense, as the linker needs to resolve the symbols from all the object files. Back then I found some source (don't remember which) explaining that the compiler does implement interning, so maybe it makes sense that both are doing it. Anyway, the point being that `#define` does not create copies, that still holds regardless. – André Fratelli Sep 22 '16 at 12:36

score 14 · Answer 2 · edited May 23 '17 at 12:01

14

See "static const" vs "#define" vs "enum". The main advantage of static is type safety.

Other than that, the #define approach introduces a flexibility of inline string concatenation which cannot be done with static variables, e.g.

#define ROOT_PATH @"/System/Library/Frameworks"
[[NSBundle bundleWithPath:ROOT_PATH@"/UIKit.framework"] load];

but this is probably not a good style :).

edited May 23 '17 at 12:01

Community

1
1

answered Jan 19 '10 at 08:30

kennytm

510,854
105
1,084
1,005

34

I'm so surprised. I had no idea `@"one string"@" another string"` was valid. – Kenny Winker Jan 19 '10 at 08:36
From your comment to cdespinosa's answer, does it mean using #define will not produce duplicatation? – user523234 Jun 02 '13 at 10:06
@user523234 it does. The compiler uses [String Interning](https://en.wikipedia.org/wiki/String_interning) – André Fratelli Jul 02 '15 at 12:14

score 6 · Answer 3 · edited May 23 '17 at 12:09

I actually would recommend neither, you should use extern instead. Objective-c already defines FOUNDATION_EXPORT which is more portable than extern, so a global NSString instance would look something like this:

.h

FOUNDATION_EXPORT NSString * const AppQuitGracefullyKey;

.m

NSString * const AppQuitGracefullyKey = @"AppQuitGracefully";

I usually put these in declaration files (such as MyProjectDecl.h) and import whenever I need.

There are a few differences to these approaches:

#define has several downsides, such as not being type safe. It is true that there are workarounds for that (such as #define ((int)1)) but what's the point? And besides, there are debugging disadvantages to that approach. Compilers prefer constants. See this discussion.
static globals are visible in the file they are declared.
extern makes the variable visible to all files. That contrasts with static.

Static and extern differ in visibility. It's also notable that neither of these approaches duplicates the string (not even #define) as the compiler uses String Interning to prevent that. In this NSHipster post they show proof:

NSString *a = @"Hello";
NSString *b = @"Hello";
BOOL wtf = (a == b); // YES

The operator == returns YES only if the two variables point at the same instance. And as you can see, it does.

The conclusion is: use FOUNDATION_EXPORT for global constants. It's debug friendly and will be visible allover your project.

score 4 · Answer 4 · edited May 23 '17 at 11:45

After doing some search (this question/answer among other things) I think it is important to say that anytime when you are using string literal @"AppQuitGracefully" constant string is created, and no matter how many times you use it it will point to the same object.

So I think (and I apologize me if I'm wrong) that this sentence in above answer is wrong: If you use a #define, there will be a separate copy of the string stored in the source on each use.

score 3 · Answer 5 · answered Jan 19 '10 at 08:29

3

I use static when I need to export NSString symbols from a library or a framework. I use #define when I need a string in many places that I can change easily. Anyway, the compiler and the linker will take care of optimizations.

answered Jan 19 '10 at 08:29

Laurent Etiemble

27,111
5
56
81

Hitendra Solanki · Answer 6 · 2015-05-14T04:55:46.393

USING #define :

you can't debug the value of identifier

work with #define and other macros is a job of Pre-Processor, When you hit Build/Run first it will preprocess the source code, it will work with all the macros(starting with symbol #),

Suppose, you have created,

#define LanguageTypeEnglish @"en"

and used this at 2 places in your code.

NSString *language = LanguageTypeEnglish;
NSString *languageCode = LanguageTypeEnglish;

it will replace "LanguageTypeEnglish" with @"en", at all places. So 2 copies of @"en" will be generated. i.e

NSString *language = @"en";
NSString *languageCode = @"en";

Remember, till this process, compiler is not in picture.

After preprocessing all the macros, complier comes in picture, and it will get input code like this,

NSString *language = @"en";
NSString *languageCode = @"en";

and compile it.

USING static :

it respects scope and is type-safe. you can debug the value of identifier

During compilation process if compiler found,

static NSString *LanguageTypeRussian = @"ru";

then it will check if the variable with the same name stored previously, if yes, it will only pass the pointer of that variable, if no, it will create that variable and pass it's pointer, next time onwards it will only pass the pointer of the same.

So using static, only one copy of variable is generated within the scope.

When to use static string vs. #define

6 Answers6

Linked