I think the title says it all :)

I'm new to Cocoa and while the purpose of many objects is obvious, others are not. For example NSInteger/NSUInteger/NSFloat/NSDouble are all replacements for the regular builtin types.

Is there any benefit to using the NS* types over the builtins? Which do you prefer and why? Are NSInteger and int the same width on 32-bit / 64-bit platforms?

+13  A: 

64-bit is actually the raison d'être for NSInteger and NSUInteger; before 10.5, those did not exist. The two are simply defined as longs in 64-bit, and as ints in 32-bit:

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

Thus, using them in place of the more basic C types when you want the 'bit-native' size.

CocoaDev has some more info.

Sören Kuklau
+29  A: 

The way I understand it is that NSInteger et al. are architecture safe versions of the corresponding C types. Basically their size vary depending on the architecture, but NSInteger, for example, is guaranteed to hold any valid pointer for the current architecture.

Apple recommends that you use these to work with OS X 10.5 and onwards, and Apple's API:s will use them, so it's definitely a good idea to get into the habit of using them. They require a little more typing, but apart from that it doesn't seem to be any reason not to use them.

This is not necessarily the case -- see my answer "uantisation issues for 64-bit runtime".

I prefer the standard c style declarations but only because I switch between several languages and I don't have to think too much about it but sounds like I should start looking at nsinteger

+26  A: 

Quantisation issues for 64-bit runtime

In some situations there may be good reason to use standard types instead of NSInteger: "unexpected" memory bloat in a 64-bit system.

Clearly if an integer is 8 instead of 4 bytes, the amount of memory taken by values is doubled. Given that not every value is an integer, though, you should typically not expect the memory footprint of your application to double. However, the way that Mac OS X allocates memory changes depending on the amount of memory requested.

Currently, if you ask for 512 bytes or fewer, malloc rounds up to the next multiple of 16 bytes. If you ask for more than 512 bytes, however, malloc rounds up to the next multiple of 512 (at least 1024 bytes). Suppose then that you define a class that -- amongst others -- declares five NSInteger instance variables, and that on a 32-bit system each instance occupies, say, 272 bytes. On a 64-bit system, instances would in theory require 544 bytes. But, because of the memory allocation strategy, each will actually occupy 1024 bytes (an almost fourfold increase). If you use a large number of these objects, the memory footprint of your application may be considerably greater than you might otherwise expect. If you replaced the NSInteger variables with sint_32 variables, you would only use 512 bytes.

When you're choosing what scalar to use, therefore, make sure you choose something sensible. Is there any reason why you need a value greater than you needed in your 32-bit application? Using a 64-bit integer to count a number of seconds is unlikely to be necessary...

Yeah, but statistically is more productive to put programmers hands off bits and bytes. We are speaking about Cocoa, not libc. On the other hand on the iPhone you may have a point, depending on the app.
It's not clear what the issue is here: My comments pertain directly to Cocoa, and an important consideration when you choose the type to represent a variable. Just because you're using Cocoa doesn't mean you never have to consider factors related to application performance...
The fact that memory is more plentiful on modern devices isn't a good excuse for wasting memory. Sure, wasting an extra 32 bits here or there is small change, but if it's a struct field or instance variable, and it's allocated thousands of times, it becomes a nickel-and-dime effect. Careless programming and unknowingly using 64-bit values when 32-bit will do causes memory bloat — if you have the opportunity to avoid it, I can't think of a good excuse to not grab the low-hanging fruit.
Quinn Taylor