关于不可知的语言：何时在签名值上使用无符号值？

什么时候在无符号变量上使用无符号变量合适？ 在for循环中怎么样？

我对此有很多意见，我想看看是否有任何类似共识的内容。

我知道Java没有unsigned值，这一定是Sun Microsystems做出的明智决定。

我很高兴在这个问题上找到了很好的对话，因为我之前从未真正考虑过。

总而言之，有符号是一个很好的常规选择-即使您不确定要确定所有数字都是正数，也要对变量进行算术运算(例如在典型的for循环情况下)。

如果您要进行掩码之类的按位操作，则无符号开始变得更有意义。或者，如果您渴望通过利用符号位来获得该额外的正范围。

就我个人而言，我喜欢签名，因为我不相信自己保持一致并避免将两种类型混合使用(如本文警告的那样)。

在上面的示例中，当" i"始终为正且范围较大将是有益的时，无符号将很有用。就像您使用"声明"语句一样，例如：

特别是当这些值永远不会改变时。

但是，如果您执行的会计程序中人们对自己的钱不负责任，并且始终处于亏损状态，那么您肯定会希望使用"签名"。

我确实同意圣人的观点，尽管有一个很好的经验法则是使用带符号的(C实际上默认为带符号的)，所以您已被覆盖。

我认为，如果您的业务案例指示负数无效，那么您将希望显示或抛出错误。

考虑到这一点，我直到最近才在一个项目中处理二进制文件中的数据并将数据存储到数据库中时才发现无符号整数。我故意"破坏"了二进制数据，并最终得到了负值而不是预期的错误。我发现即使转换了值，该值对于我的业务案例也无效。
我的程序没有出错，最终我将错误的数据输入数据库。如果使用uint并且程序失败，那就更好了。

比较带符号和无符号类型时，C和C ++编译器将生成警告。在示例代码中，您无法使循环变量无符号，并且使编译器在没有警告的情况下生成代码(假设已打开警告)。

自然地，您在编译警告时一路向上，对吗？

而且，您是否考虑过将"警告作为错误处理"进行编译以使这一步骤更进一步？

使用带符号的数字的缺点是有一种使它们重载的诱惑，例如，值0-> n是菜单选择，而-1表示什么也没有选择-而不是创建具有两个变量的类，一个用于指示是否选择了某项，并指示另一项存储该选择。在不知不觉中，您正在各处测试负数，并且编译器抱怨您希望如何将菜单选择与菜单选择的数量进行比较-但这很危险，因为它们是不同的类型。所以不要那样做。

size_t通常是一个不错的选择，如果使用STL类，则通常选择size_type。