NSInteger应该到处使用吗?

时间:2013-09-11 01:21:58

标签: objective-c 64-bit

现在有一款iPhone采用64位架构。 long变为64位(而int仍然是32位),并且在任何地方使用NSInteger现在都是long,所以64位不是32位。而twitter有很多人说“我很高兴我在任何地方都使用过NSInteger而不是int”。

如果你需要存储一个不超过32位的值(例如在一个只循环25次的循环中),为什么要使用long,因为32位(至少)高位将是空。

如果程序已经处理了32位整数,那么当它占用更多内存时,使用64位整数会带来什么好处呢?

同样会出现使用64位整数给出使用32位整数的不同结果的情况。因此,如果您使用NSInteger,则某些内容可能适用于iPhone 5S但不适用于较旧的设备,而如果明确使用int或long,则结果在任何设备上都是相同的。

3 个答案:

答案 0 :(得分:1)

  

如果你需要存储一个不超过32位的值......为什么要长时间使用?

如果你能真正做出这种保证,那么绝对没有理由在32位上重写64位类型。对于有界循环,计数器和通用算术等简单操作,32位整数就足够了。但是对于更复杂的操作,尤其是那些高性能应用程序所需的操作 - 例如那些执行音频或图像处理的操作 - 处理器在64位模式下可以处理的数据量的增加是非常重要的。

  

如果程序已经处理了32位整数,那么当它占用更多内存时,使用64位整数会带来什么好处呢?

你使用更多内存似乎是一件坏事。通过将某些数据类型的大小加倍,它们可以被寻址到内存中的更多位置,并且可以寻址的内存越多,操作系统花费更少的时间来加载代码。此外,在处理器总线中具有两倍数量的通道数量等于可以在一次执行中处理更多值的数量级,并且寄存器大小的增加意味着可以保持更多数据的数量级。一个登记册。简而言之,这相当于大多数应用程序的速度几乎自动加倍。

  

同样会出现使用64位整数给出使用32位整数的不同结果的情况? ...

是的,但不是你想的那样。 32位数据类型和操作以及64位操作(大多数在软件中模拟,或由32位主机中的特殊硬件或操作码模拟)在大小方面“相对稳定”。您不能在64位体系结构上做出几乎同样多的保证,因为不同的编译器实现了不同版本的64位数据类型(请参阅LP64, SILP64, and LLP64)。实际上,这意味着将64位类型转换为32位类型 - 比如指向int的指针 - 保证会导致信息丢失,但是在保证为64位的两种数据类型之间进行转换 - 指针和长在LP64上 - 是可以接受的。 ARM通常使用LP64编译(所有int都是32位,所有long都是64位)。同样,大多数开发人员不应该受到开关的影响,但是当你开始处理你试图以整数存储的任意大数字时,精度就成了问题。

出于这个原因,我建议在公共接口中使用NSUInteger和NSInteger,以及没有固有边界检查或溢出保护的API。例如,TableView请求NSUInteger数据量不是因为它担心32位和64位数据结构,而是因为它无法保证编译它的体系结构。 Apple考虑制作独立于架构的数据类型实际上是一种奢侈,考虑到你需要做很少的工作才能使代码编译并在两种架构中“正常工作”。

答案 1 :(得分:-1)

NSInteger的内部存储可以是众多不同支持类型中的一种,这就是为什么你可以在任何地方使用它而不需要担心它,这就是它的全部要点。

答案 2 :(得分:-1)

如果您的应用程序在32位或64位引擎上运行,并且使用__LP64__宏将您的变量转换为正确的数据类型,那么Apple会注意向后兼容性。

#if __LP64__ 
    typedef long NSInteger; 
    typedef unsigned long NSUInteger; 
#else 
    typedef int NSInteger; 
    typedef unsigned int NSUInteger; 
#endif 
相关问题