objective-c - 为什么 NSIndexPath 的 row 属性是有符号整数？

Question

为什么 NSIndexPath 的 row 属性是有符号整数？

它是否可以采用“有效”的负值？

编辑

直到今天我设置LLVM来检查符号比较时，我才想到这一点。这使得编译器在出现 indexPath.row <= [someArray count] 时发出警告。或类似的。

Answer 1

如果使用负数会怎样？

使用负值是不明智的，如果你这样做，你会得到疯狂的结果

NSIndexPath* path = [NSIndexPath indexPathForRow:-2 inSection:0];

上面的结果是 0 的部分和 4294967294 的行(对我来说这看起来像 NSUInteger 的下溢!)请放心，这只发生在 UIKit Additions 类别中，而不是在 NSIndexPath 本身。查看 NSIndexPath 背后的概念，保留负值确实没有意义。那为什么？

(可能)为什么会这样

OS X 的核心对象 NSIndexPath 使用 NSUInteger 作为其索引，但 UIKit Addition 使用 NSInteger。该类别仅构建在核心对象之上，但在 NSUInteger 上使用 NSInteger 不提供任何额外功能。

为什么会这样，我不知道。我的猜测(并且我规定猜测)是不是在首次启动 iOS 时出现了天真的 API 失误。当 UITableView 在 iOS 2 中发布时，它使用 NSInteger 来处理各种事情(例如 numberOfSections)。想一想:这在概念上没有意义，你不能有负数的部分。现在即使在 iOS 6 中，它仍然使用 NSInteger，因此不会破坏以前应用程序与 TableView 的兼容性。

除了 UITableView 之外，我们还添加了 NSIndexPath，它与 TableView 结合使用以访问它的行等。因为它们必须协同工作，所以它们需要兼容的类型(在本例中为 NSInteger)。

将类型全面更改为 NSUInteger 会破坏很多东西，为了安全的 API 设计，所有内容都需要重命名，以便 NSInteger 和 NSUInteger 对应物可以安全地并行工作边。 Apple 可能不希望出现这种麻烦(开发人员也不希望如此!)，因此他们将其保存在 NSInteger 中。