How are string constants in Objective-C stored/retrieved?

Can so开发者_StackOverflowmeone explain where and how string constants are stored by the compiler and how they're accessed by the runtime?

First the obligatory: you should shouldn't care how the compiler does this; anything based on how the compiler does this is a dangerous reliance on something that is not guaranteed and can change based on how the compiler optimizes. Do not write code based on this. Really. OK, we've got that out of the way.

Say you have code like this:

NSString *something = @"I'm a constant";

The compiler will generate this:

    .section    __TEXT,__cstring,cstring_literals
l_.str:                                 ## @.str
    .asciz   "I'm a constant"

As you see, it's stored in the __TEXT section, along with your code, as a cstring literal. Over in __DATA, it'll store the constant CFString itself like this:

    .section    __DATA,__cfstring
    .align  4                       ## @_unnamed_cfstring_
L__unnamed_cfstring_:
    .quad   ___CFConstantStringClassReference
    .long   1992                    ## 0x7c8
    .space  4
    .quad   l_.str
    .quad   14                      ## 0xe

First, it stores the CFType (CFConstantStringClassReference). Then internal information about the string (is it immutable, how is it deallocated, is it unicode, etc), a pointer to the cstring, and a length (14). If you want the details on the structure, pull down the CF sources from opensource.apple.com and look at CFString.c. It explains the whole "internal information" field pretty well. (Pull them from Snow Leopard; Apple doesn't publish them as part of iOS, but they're the same.)

A second constant string would look like this, just to demonstrate how the symbol naming is done for the assembler.

    .section    __TEXT,__cstring,cstring_literals
l_.str2:                                ## @.str2
    .asciz   "%@"

    .section    __DATA,__cfstring
    .align  4                       ## @_unnamed_cfstring_3
L__unnamed_cfstring_3:
    .quad   ___CFConstantStringClassReference
    .long   1992                    ## 0x7c8
    .space  4
    .quad   l_.str2
    .quad   2                       ## 0x2

If you want to get a better handle on this, just ask Xcode to generate the assembly for a simple file and see what it does. Oh, and of course you should never use this information because gcc could change at any time. But it's great stuff to dig into.

You should create a header file like

// Constants.h
extern NSString * const MyFirstConstant;
extern NSString * const MySecondConstant;
//etc.

You can include this file in each file that uses the constants or in the pre-compiled header for the project.

You define these constants in a .m file like

// Constants.m
NSString * const MyFirstConstant = @"FirstConstant";
NSString * const MySecondConstant = @"SecondConstant";

Constants.m should be added to your application/framework's target so that it is linked in to the final product.

The advantage of using string constants instead of #define'd constants is that you can test for equality using pointer comparison (stringInstance == MyFirstConstant) which is much faster than string comparison ([stringInstance isEqualToString:MyFirstConstant])