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

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

for (unsigned int i = 0; i < someThing.length(); i++) {  
    SomeThing var = someThing.at(i);  
    // You get the idea.  
}

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

解决方案：

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

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

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

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

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

#declare BIT1 (unsigned int 1)
#declare BIT32 (unsigned int reallybignumber)

尤其是当这些值永远不会改变时。

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

我确实同意圣人的观点，尽管有一个很好的经验法则是使用带符号的符号，而C实际上是默认符号，所以我们很容易理解。

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

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

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

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

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

我认为，如果业务案例表明负数无效，那么我们将希望显示或者抛出错误。

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