In Cocoa, do you prefer NSInteger or int, and why?

Question

NSInteger / NSUInteger are Cocoa-specific replacements for regular built-in types.

Is there any use to using NS * types over inline modules? What do you prefer and why? Are NSInteger and int same width on 32-bit / 64-bit platforms?

Answer 1

I understand that NSInteger et al. are architecturally safe versions of the corresponding C types. Basically, their size varies by architecture, but NSInteger, for example, is guaranteed to contain any valid pointer for the current architecture.

Apple recommends using them for OS X 10.5 and later, and the Apple API: s will use them, so it’s definitely a good idea to get used to them. They require a bit more typing, but other than that, there seems to be no reason not to use them.

Answer 2

Quantization Issues for a 64-Bit Runtime

In some situations, there may be good reasons to use standard types instead of NSInteger : an “unexpected” memory burst on a 64-bit system.

It is clear that if an integer is 8 instead of 4 bytes, the amount of memory received by the values ​​doubles. Given that not every value is an integer, you generally should not expect your application’s memory to double. However, Mac OS X allocates memory changes based on the amount of requested memory.

Currently, if you request 512 bytes or less, malloc rounded to the next multiple of 16 bytes. However, if you request more than 512 bytes, malloc rounded to the next multiple of 512 (at least 1024 bytes). Suppose you define a class that, among other things, declares five variables of an NSInteger instance, and on a 32-bit system, each instance takes, say, 272 bytes. On a 64-bit system, instances theoretically require 544 bytes. But due to the memory allocation strategy, each will take up 1024 bytes (almost four times as much). If you use a large number of these objects, the memory size of your application may be significantly larger than you might expect. If you replace the NSInteger variables with sint_32 variables, you will only use 512 bytes.

When you choose which scalar to use, so make sure you choose something reasonable. Is there a reason why you need a value greater than what you need in a 32-bit application? Using a 64-bit integer to count a few seconds is hardly needed ...

Answer 3

64-bit is actually the raison d'être for NSInteger and NSUInteger; up to 10.5 such cases did not exist. These two are simply defined as long in 64-bit and as ints in 32-bit:

 #if __LP64__ || NS_BUILD_32_LIKE_64 typedef long NSInteger; typedef unsigned long NSUInteger; #else typedef int NSInteger; typedef unsigned int NSUInteger; #endif 

Thus, using them instead of the simpler C types when you want a “bit-native” size.

CocoaDev has more information.

Answer 4

I prefer standard c style declarations, but only because I switch between several languages ​​and I don’t need to think too much about it, but it seems like I should start looking at nsinteger

Answer 5

To import and export data to files or via a network, I use UInt32 , SInt64 , etc.

They are guaranteed to have a certain size regardless of architecture and help port code to other platforms and languages ​​that also use these types.