ARM64 and You
or how I rue NSInteger
NSInteger is now 64-bit on ARM64; that means a bunch of useless warnings everywhere about precision loss right? WRONG.
Here's a hint: "Comparison of constant 'NSNotFound' with expression of type 'int' is always true"
. Uh-oh. Fix your integer warnings and kick yourself for not using NSInteger because every count, index, et al in the whole of Cocoa appears to be NSInteger or NSUInteger. (This specific warning means your fancy searching will never find results.)
Are C-style varargs garbage due to complete lack of metadata? Yes.
Does that mean every NSLog()
or other format-style statement requires a different format specifier now that NSInteger
has different definitions? Yes, yes it does.
Why? That's stupid! Because otherwise the callee can't tell where the parameter is or what size it is. You see on some platforms arguments start in registers and spill to the stack, so if argument one is 32 bits it... hey wait, where are you going?
Should we still have to deal with that in the Year of our Lord Two Thousand and Fourteen? No.
Can you save me from that 1970s bullshit? Why yes, yes I can:
NSLog(@"Array.Count: %i", array.count);
becomes
NSLog(@"Array.Count: %@", @(array.count));
Technically you could use %tu
(ptrdiff_t) or %zd
(size_t) but I prefer the @() form and thanks to the magic of tagged pointers on ARM64, the second form is nearly free and does not actually box the value as an instance of NSNumber
.
The future is so bright you're gonna need shades.
This blog represents my own personal opinion and is not endorsed by my employer.