升级到iOS 7.1 SDK后出错 – 不再允许使用精度损失的隐式转换
我只是将Xcode + iOS SDK升级到最新版本（5.1 / 7.1），现在我得到了一些关于隐式转换丢失精度的错误（ NSInteger为int等）。
有没有人知道是否有编译器标志或让我告诉编译器把它们当作警告而不是再次出错？ 到目前为止我找不到任何东西。 我真的不想通过代码，并在各地添加明确的演员，因为这将在很多地方。
这是一个很好的理由错误。 整个代码库中的NSInteger将确保在编译32位和64位iOS设备的代码时，它们的处理是一致的。 在32位的世界里，NSInteger和int是一样的，但是随着iPhone 5S和iPad Air的到来，iOS不再只是32位。
正如其他人所说的，如果你不想用现代设备来解决问题，那么真的没有办法解决这个问题。
如果你只是想恢复工作并在以后处理这个问题，那么你需要从项目的Build Settings中的“Valid Architectures”和“Architectures”项中删除arm64 。
正如其他人所说，你真的应该修正警告，但这是一个苹果的令人讨厌的小惊喜（即，在Xcode 5.1添加arm64架构build设设置），所以我完全可以明白，想把这些警告一段时间并在决定升级之前处理您正在从事的工作。
事实上，XCode现在包含了arm64架构。 NSInteger与NSObjCRuntime.h中定义的完全不同：
#if __LP64__ || (TARGET_OS_EMBEDDED && !TARGET_OS_IPHONE) || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64 typedef long NSInteger; typedef unsigned long NSUInteger; #else typedef int NSInteger; typedef unsigned int NSUInteger; #endif
为了处理它，你应该改善你的代码库。 首先，你必须真正一致。 NSInteger只分配给NSInteger，而不是int。 避免所有types的：
int i = [aString integerValue]（因为它返回一个NSInteger）
但
NSInteger我= [aString integerValue]（如果它是一个长types，那么你不会有任何麻烦。）
此外，另一个问题可能是当你想从一个值创build一个string。 你可以做的是这样的：
#define cL(v) (long)(v) #define cUL(v) (unsigned long)(v) NSLog(@"array.count: %ld", cUL(anArray.count));
array.count在armv7（s）下返回一个unsigned int，在arm64下返回一个unsigned long。 通过总是投入一个无符号的长，你将不会再面临任何警告，更重要的是，不会有任何bug。
这个“逻辑”是由苹果自己在一些技术讲座video中介绍的： https ： //developer.apple.com/tech-talks/videos/ （video“构build现代iOS游戏”，播放video大约10m00s）
你应该按照他们应该的方式去施展他们。 苹果公司并不是无缘无故的抱怨，它也可以确保你不会在晚些时候得到任何奇怪的意外行为。 我build议你去把它们全部扔下。 这是极端的，但很好，它很干净。