ios - 使用 NSInteger 而不是 int 的好处？

Question

我试图了解在针对 32 位和 64 位架构进行开发时，开发会受到怎样的影响。根据我迄今为止的研究，我了解到 int 始终是 4 个字节，无论运行该应用程序的设备的体系结构如何。但是 NSInteger 在 32 位设备上是 4 个字节，在 64 位设备上是 8 个字节。我得到的印象是 NSInteger 是“更安全的”并且值得推荐，但我不确定这样做的原因是什么。

我的问题是，如果您知道您使用的可能值永远不会很大(也许您正在使用它来索引一个包含 200 个项目的数组或将对象的数量存储在一个数组中)，为什么将其定义为 NSInteger？当你不使用它时，它只会占用 8 个字节。在这些情况下，将其定义为 int 是否更好？如果是这样，在什么情况下您希望使用 NSInteger(而不是 int 或 long 等)？显然，如果您需要使用更大的数字，则可以使用 64 位架构。但是如果你需要它也能在 32 位设备上工作，你会不会使用 long long 因为它在 32 位设备上也是 8 个字节？我不明白为什么人们会使用 NSInteger，至少在创建一个在两种架构上运行的应用程序时是这样。

此外，我想不出一种接受或返回原始类型的方法 - int，而是利用 NSInteger，我想知道它是否有比只是值的大小。例如，(NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section。我想了解为什么会这样。假设可能有一个包含 2,147,483,647 行的表，当您再添加一个行时，在 32 位设备上会发生什么情况 - 它会环绕到 -2,147,483,647 吗？在 64 位设备上，它将是 2,147,483,648。 (为什么要返回一个带符号的值？我认为它应该是无符号的，因为你不能有负数的行。)

最终，我想更好地了解这些数字数据类型的实际使用，也许一些代码示例会很棒!

Answer 1

我个人认为，64位其实是NSInteger和NSUInteger存在的理由；在 10.5 之前，这些不存在。两者在64位简单定义为long，在32位定义为int。

NSInteger/NSUInteger 被定义为这些类型之一的*动态 typedef*s，它们的定义如下:

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

因此，当您需要“位原生”大小时，可以使用它们代替更基本的 C 类型。

我建议您通读此链接。 CocoaDev has some more info.

有关您应该为这些类型中的每一种使用的正确格式说明符，请参阅 String Programming Guide's section on Platform Dependencies