【发布时间】：2010-09-06 00:53:25
【问题描述】：
NSInteger/NSUInteger 是 Cocoa 定义的常规内置类型的替代品。
使用 NS* 类型比使用内置类型有什么好处吗？你更喜欢哪个？为什么？ NSInteger 和 int 在 32 位/64 位平台上的宽度是否相同？
【问题讨论】：
标签： objective-c cocoa types
【发布时间】：2010-09-06 00:53:25
【问题描述】：
我理解它的方式是 NSInteger 等人。是相应 C 类型的体系结构安全版本。基本上它们的大小因架构而异，但例如 NSInteger 可以保证保存当前架构的任何有效指针。
Apple 建议您将它们用于 OS X 10.5 及更高版本，Apple 的 API:s 将使用它们，因此养成使用它们的习惯绝对是个好主意。它们需要更多的输入，但除此之外，似乎没有任何理由不使用它们。
【讨论】：
-
不一定是这种情况——请参阅我的回答“64 位运行时的仿真问题”。
64 位运行时的量化问题
在某些情况下，可能有充分的理由使用标准类型而不是 NSInteger：在 64 位系统中出现“意外”内存膨胀。
很明显，如果整数是 8 而不是 4 字节，则值占用的内存量会加倍。但是，鉴于并非每个值都是整数，您通常不应期望应用程序的内存占用量翻倍。但是，Mac OS X 分配内存的方式会根据请求的内存量而变化。
目前，如果您要求 512 字节或更少，malloc 会向上取整为 16 字节的下一个倍数。但是，如果您要求超过 512 个字节，malloc 会向上舍入到 512 的下一个倍数（至少 1024 个字节）。假设您定义了一个类——其中包括——声明了五个NSInteger 实例变量，并且在 32 位系统上，每个实例占用例如 272 个字节。在 64 位系统上，实例理论上需要 544 个字节。但是，由于内存分配策略，每个实际上将占用 1024 字节（几乎增加了四倍）。如果您使用大量这些对象，您的应用程序的内存占用量可能会比您预期的要大得多。如果您将NSInteger 变量替换为sint_32 变量，您将只使用512 个字节。
因此，当您选择要使用的标量时，请确保选择合理的值。是否有任何理由需要一个大于 32 位应用程序所需的值？不太可能需要使用 64 位整数来计算秒数...
【讨论】：
-
是的，但从统计上讲，让程序员放弃比特和字节的工作效率更高。我们说的是 Cocoa，而不是 libc。另一方面，在 iPhone 上，您可能会有所了解，具体取决于应用程序。
-
不清楚这里的问题是什么：我的 cmets 与 Cocoa 直接相关，当您选择表示变量的类型时，这是一个重要的考虑因素。仅仅因为您使用 Cocoa 并不意味着您永远不必考虑与应用程序性能相关的因素...
-
现代设备上的内存更加丰富这一事实并不是浪费内存的好借口。当然，在这里浪费额外的 32 位或有很小的变化，但如果它是一个结构字段或实例变量，并且它被分配了数千次，它就会变成五分钱的效果。粗心的编程和在不知情的情况下使用 64 位值（而 32 位）会导致内存膨胀——如果你有机会避免它，我想不出一个很好的借口来不抓住唾手可得的果实。
64 位实际上是 NSInteger 和 NSUInteger 存在的理由；在 10.5 之前，那些不存在。两者在 64 位中被简单地定义为 long，在 32 位中被定义为 int：
#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 目前没有那篇文章。
-
是的，它没有.. & 以后请不要发布链接.. 如果可能，请在此处发布答案。仅发布链接违反了 stackoverflow 的回答指南。
我更喜欢标准的 c 风格声明，但这只是因为我在几种语言之间切换，我不必考虑太多，但听起来我应该开始研究 nsinteger
【讨论】：
为了将数据导入和导出到文件或通过网络，我使用 UInt32、SInt64 等...
无论架构如何，它们都保证具有一定的大小，并有助于将代码移植到也共享这些类型的其他平台和语言。
【讨论】：