Why NSNumber literals cannot be used in static declarations

Question

I'm declaring:

static NSString *a = @"a";

and this is a correct declaration in iOS6 (it should be more correct to use the compiler version but I do not know it at the moment). I thought that with number literals also:

static NSNumber *b=@1;

could be a valid declaration. Compiler tells me that initializer element is not a compile time constant. This surprises me a bit. Since NSNumber is immutable as NSString and since I'm using a literal as in string case, I thought it could be valid as well.

Does anybody have a reasonable explanation about this difference?

Answer 1

The first line is a compile-time constant since you are assigning @"a" and not something like static NSString *a = [NSString stringWithFormat:@"a"];(That will throw the same error)

But for an NSNumber, static NSNumber *b = @1; is actually equivalent to static NSNumber *b = [NSNumber numberWithInt:1];. For more details check Objective-C Literals.

Note that in the above case, the right side is not a compile-time constant. It is an expression that must be evaluated at runtime. In C and Objective-C, static variables must be initialized with compile-time constants.

If you want to have NSNumber as a const you can check with the approaches mentioned here Objective C - How to use extern variables?.

Also check this on Objective C literals from Mike Ash,

It's important to note that none of the new literal syntax qualifies as a compile-time constant.

And,

NSString literals are also compile-time constants, because of a tight coupling between the compiler and the libraries. There's a special NSString subclass called NSConstantString with a fixed ivar layout:

This tight coupling has advantages, like producing legal global variable initializers, and requiring no extra code to run to build the object at runtime. However, there are big disadvantages as well. The NSConstantString layout is set forever. That class must be maintained with exactly that data layout, because that data layout is baked into thousands of third-party apps. If Apple changed the layout, those third-party apps would break, because they contain NSConstantString objects with the old layout.

If NSArray literals were compile-time constants, there would need to be a similar NSConstantArray class with a fixed layout that the compiler could generate, and that would have to be maintained separately from other NSArray implementations. Such code could not run on older OSes which didn't have this NSConstantArray class. The same problem exists for the other classes that the new literals can produce.

This is particularly interesting in the case of NSNumber literals. Lion introduced tagged pointers, which allow an NSNumber's contents to be embedded directly in the pointer, eliminating the need for a separate dynamically-allocated object. If the compiler emitted tagged pointers, their format could never change, and compatibility with old OS releases would be lost. If the compiler emitted constant NSNumber objects, then NSNumber literals would be substantially different from other NSNumbers, with a possible significant performance hit.

Instead, the compiler simply emits calls into the framework, constructing the objects exactly like you would have done manually. This results in a bit of a runtime hit, but no worse than building them yourself without the new syntax, and makes for a much cleaner design.