如果NSInteger的真正在任何地方使用？ [英] Should NSInteger really be used everywhere?
问题描述
现在有一个iPhone与64位架构的到来。 长变成64位（而 INT 仍然是32位），到处都NSInteger的已使用现在是一个长等64位不是32和Twitter有不少人说：我很高兴我已经用NSInteger的无处不在不是int。
如果你需要存储的值不超过（在一个循环中只循环25次为例），为什么要长期使用32位的，因为32（至少）高位将是空。
如果该方案曾在32位整数，那还有什么用的64位整数提供，当它使用了更多的内存？好处
又会有情况下使用的是64位整数给出不同的结果，使用一个32位的整数。所以，如果你使用NSInteger的那么就有可能工作在iPhone 5S，但不是在一个较旧的设备，而如果没有明确使用int或长那么结果将是在任何设备上一样。
如果你需要存储的值不超过32位...为什么要长期使用？
如果你真能保证做到这一点，那么就绝对没有理由的价值超过32位的一个64位的类型。对于像界回路，计数器和通用算术简单的操作，32位整数就足够了。但是对于更复杂的操作，尤其是那些高性能应用所需 - 如那些执行音频或图像处理 - 的增加的数据量的处理器可以处理在64位模式下是显著
如果该方案曾在32位整数，那还有什么用的64位整数提供，当它使用了更多的内存？好处
您让使用更多的内存似乎是一件坏事。通过一些数据类型的规模扩大一倍，它们可以向更多的地方在内存中，与更多的内存可以被解决，在更短的时间操作系统加载花费code。此外，具有在一个处理器总线车道两次数据量等于可在单一去处理数量级以上的值的顺序，并且增加寄存器大小意味着幅度更多数据的顺序可以保持围绕在一个寄存器。这相当于，在最简单的术语，大多数应用的速度的近自动增加一倍。
又会有情况下使用的是64位整数给出不同的结果，使用一个32位的整数。 ......
是的，但不是在路上，你会觉得。 32位数据类型和操作以及64位操作（最模拟以软件，或通过特殊的硬件或运算codeS在32位主机）都在它们的大小的术语相对稳定的。你不能在64位架构使几乎同样多的保障，因为不同的编译器实现不同版本的64位数据类型（见的 LP64，SILP64和LLP64 ）。实际上，这意味着铸有64位类型到32位的类型 - 说一个int指针 - 是保证导致信息丢失，但保证是64位两种数据类型之间的铸造 - 指针和长在LP64 - 是可以接受的。 ARM通常编译使用LP64（所有的整数都是32位的，所有渴望都是64位）。同样，大多数开发人员不应该受到开关，但是当你开始处理您尽量存放在整数任意大的数字，那么precision成为一个问题。
出于这个原因，我建议在公共接口使用NSUInteger和NSInteger的，和原料药在没有固有的边界检查或溢流警卫。例如，一个TableView中请求数据的NSUInteger量，不是因为它是担心32位和64位数据结构，但因为它可以使任何有关在其它的编译架构保证。苹果公司企图使体系结构无关的数据类型实际上是有点奢侈的，考虑到你怎么一点工作要做，让您的code编译，只是工作，在两种架构。
Now there is an iPhone coming with 64-bit architecture. long becomes 64 bits (while int remains 32-bit) , and everywhere NSInteger has been used is now a long and so 64-bits not 32. And twitter has quite a few people saying "I'm glad I've used NSInteger everywhere not int".
If you need to store a value that doesn't exceed 32 bits (for example in a loop which only loops 25 times), why should a long be used, because the 32 (at least) upper bits are going to be empty.
If the program has worked on 32-bit integers, then what benefit does using 64-bits for integers provide, when it uses up more memory?
Also there will be situations where using a 64-bit integer gives a different result to using a 32-bit integer. So if you use NSInteger then something may work on an iPhone 5S but not on an older device, whereas if int or long is explicitly used then the result will be the same on any device.
If you need to store a value that doesn't exceed 32 bits... why should a long be used?
If you can really make that guarantee, then there is absolutely no reason to value a 64 bit type over a 32 bit one. For simple operations like bounded loops, counters, and general arithmetic, 32-bit integers suffice. But for more complex operations, especially those required of high-performance applications - such as those that perform audio or image processing - the increase in the amount of data the processor can handle in 64 bit modes is significant.
If the program has worked on 32-bit integers, then what benefit does using 64-bits for integers provide, when it uses up more memory?
You make using more memory seem like a bad thing. By doubling the size of some data types, they can be addressed to more places in memory, and the more memory that can be addressed, the less time the OS spends loading code. In addition, having twice the amount of lanes for data in a processor bus equates to an order of magnitude more values that can be processed in a single go, and the increase in register size means an order of magnitude more data can be kept around in one register. This equates to, in simplest terms, a nearly automatic doubling of the speed of most applications.
Also there will be situations where using a 64-bit integer gives a different result to using a 32-bit integer? ...
Yes, but not in the way you'd think. 32-bit data types and operations as well as 64-bit operations (most simulated in software, or by special hardware or opcodes in 32-bit hosts) are "relatively stable" in terms of their sizes. You cannot make nearly as many guarantees on a 64-bit architecture because different compilers implement different versions of 64-bit data types (see LP64, SILP64, and LLP64). Practically, this means casting a 64 bit type to a 32-bit type - say a pointer to an int - is guaranteed to lead to information loss, but casting between two data types that are guaranteed to be 64 bits - a pointer and a long on LP64 - is acceptable. ARM is usually compiled using LP64 (all ints are 32-bit, all longs are 64-bit). Again, most developers should not be affected by the switch, but when you start dealing with arbitrarily large numbers that you try to store in integers, then precision becomes an issue.
For that reason, I'd recommend using NSUInteger and NSInteger in public interfaces, and APIs where there is no inherent bounds checking or overflow guards. For example, a TableView requests an NSUInteger amount of data not because it's worried about 32 and 64 bit data structures, but because it can make no guarantees about the architecture upon which it's compiled. Apple's attempt to make architecture-independent data types is actually a bit of a luxury, considering how little work you have to do to get your code to compile and "just work" in both architectures.
这篇关于如果NSInteger的真正在任何地方使用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
