How to Lookup a String Constant at Runtime in Objective-C

How do I lookup a string constant at runtime in Objective-C?

You can use CFBundleGetDataPointerForName to lookup a constant's value at runtime

NSString *lookupStringConstant(NSString *constantName) {
    void ** dataPtr = CFBundleGetDataPointerForName(CFBundleGetMainBundle(), (__bridge CFStringRef)constantName);
    return (__bridge NSString *)(dataPtr ? *dataPtr : nil);
}

Example use:

NSString *version = lookupStringConstant(@"VungleSDKVersion");
NSLog(@"Version = %@",version);

How to access constant string in runtime using a string which holding its name?

Use a map with the key as the constant name and the value as the constant value:

static NSDictionary *_constants = @{

    @"contentDisplayDateKeyPath" : @"content.display_date",
    @"contentIDKeyPath"          : @"content.id",
    // etc.
};

...

NSString *constantName = @"contentDisplayDateKeyPath";
NSString *constantValue = _constants[constantName];

Check if constant is defined at runtime in Obj-C

Jasarien's answer is roughly correct, but is prone to issues under LLVM 1.5 where the compiler will optimise the if-statement away.

You should also be comparing the address of the constant to NULL, rather than nil (nil has different semantics).

A more accurate solution is this:

BOOL isKeyboardBoundsKeyAvailable = (&UIKeyboardBoundsUserInfoKey != NULL);
if (isKeyboardBoundsKeyAvailable) {
  // UIKeyboardBoundsUserInfoKey defined
}

Objective-C – access extern const with a string containing its name?

If get what you are saying there is no builtin way to get the const pointer value from a string ... so there isnt NSConstantFromName(@"xy)

you could it yourself though

NSString *const SCConstantByName(NSString *name) {
    if[(name isEqualToString:@"SCImportantString"])
        return SCImportantString;
}

or for many have a static dict... like the localizables also work:

NSString *const SCConstantByName(NSString *name) {
    id dict = nil;
    if(!dict) {
        dict = @{@"SCImportantString", SCImportantString};

    return dict[name];
}

Constants in Objective-C

You should create a header file like:

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

(You can use extern instead of FOUNDATION_EXPORT if your code will not be used in mixed C/C++ environments or on other platforms.)

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]) (and easier to read, IMO).

How to access a constant using a String holding its name

You would not be able to do this: unlike instance variables, #define-d constants do not leave a trace after the preprocessor is done with them. They leave no metadata behind - all instances of KDSomeItem in the body of your program will be replaced with 1 even before the Objective C compiler proper gets to analyze your code.

If you need the constant names to be available at run time, you would need to build all the necessary metadata yourself. In order to do that, you may want to look into "stringizing" operator of the preprocessor:

#define STR(X) #X

This macro can be applied to a preprocessor constant, and produce a C string literal with its name:

const char *nameOfKDSomeItem = STR(KDSomeItem); // same as "KDSomeItem"

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

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.

---

Related Topics