为什么在“numberOfSectionInTableView:”中使用 NSInteger 而不是 NSUInteger？答案

【问题标题】：Why NSInteger instead of NSUInteger in "numberOfSectionInTableView:"?为什么在“numberOfSectionInTableView:”中使用 NSInteger 而不是 NSUInteger？
【发布时间】：2012-10-28 02:34:15
【问题描述】：

UITableView 数据源方法numberOfSectionsInTableView: 的返回类型为NSInteger。然而，一个 UITableView 不能有负数的行；它有 0 行或更多行，那么为什么返回类型是 NSInteger？这不允许与返回负整数有关的崩溃吗？

【问题讨论】：

我认为没有充分的理由。它应该是未签名的。
@EricS - 在我阅读下面 borrrden 的回答之前，我同意你的看法。
@stackmonster - 部分是因为我想知道 Apple 是否粗心并在分配返回值类型 NSInteger 时犯了错误，但主要是因为我对方法的设计感兴趣，以及什么会影响 Apple 工程师使此特定方法具有此特定返回类型，当我问这个问题时，这似乎违反直觉。
我完全不明白 borrrden 的回答。节数只能为零或更高。几乎按照定义，它应该是一个无符号整数。在 open() 之类的情况下，-1 表示错误条件，因此它确实有意义——为变量设置一个无效值很方便，例如指针为 NULL/nil。
Apple 似乎正试图遵循某种约定，即始终使用 NSInteger，即使它没有意义。这些方法的返回类型并不像它们使用 NSInteger 作为 numberOfRowsInSection 的参数类型那样糟糕，其中一个相当常见的实现可能是使用该部分作为 NSArray 的索引。发生这种情况时，我必须手动将类型转换为 NSUInteger，如 [mySectionArray objectAtIndex:(NSUInteger)section]，因为它们传入的是 NSInteger 而不是 NSUInteger

标签： ios crash uitableview nsuinteger

【解决方案1】：

您不能使用无符号整数检查 (if var < 0) return;。这是选择一个的标准原因。真正使用无符号整数的唯一原因是，如果您需要更大的数字空间，并且您可以保证输入永远不会尝试小于零。

【讨论】：

我认为需要额外的空间与这样的决定无关。如果某物不可能是负值，则应将其声明为无符号类型。 Apple 甚至不能说这就是他们在这里使用 NSInteger 的原因：如果这是他们的原因，那么他们也应该在 NSArray count] 和其他 NSArray 方法上使用 NSInteger。
@TimDean 考虑一下。一些愚蠢的用户从他们的 numberOfSections 方法返回 -1。突然间，他们的表有数十亿行，而它不应该这样做。为什么不把它变成一个有符号整数然后说“嘿，笨蛋，你用的是负值”？我并不是说他们就是这样做的，但我认为这是在负值没有意义的情况下返回有符号整数的正当理由。至于 NSArray，Apple 控制那里的整个管道，因此用户不会在返回不正确的值时出错。
用这种方式来证明这一点似乎有些牵强。看看numberOfRowsInSection 方法，再一次传入一个NSInteger。 Apple 在这里控制管道，可以确定没有传入负值，但在这里他们传入的是 NSInteger 而不是 NSUInteger。最后，我认为理性的人可能会不同意哪种策略最适合任何特定情况。但是只有当你需要额外的空间时才使用 NSUInteger，我买不到，而且很明显苹果也不总是这样。
@TimDean 我同意没有一个标准商定的理由来使用一个或另一个。但是，我不同意苹果控制numberOfRowsInSection 的管道。这是用户可以从他们自己的类返回以影响表视图的另一种数据源方法。我想我看到它的方式是“当有符号值覆盖有效范围并且是默认值时，为什么还要使用无符号值？”
我对@987654325@ 的引用专门讨论了传递给方法的部分索引值in，而不是它返回的内容。 Apple 控制通过 section 参数传递给该方法的内容，但它却将其声明为 NSInteger（如果我碰巧将该值用作 NSArray 的索引，这会让我对 NSUInteger 进行烦人的强制转换）。我对“为什么要麻烦”的回答很简单：界面应该尽可能的不言自明。如果您从不打算支持负值，请不要让我通过不同的声明来研究它。