我应该使用uint在C＃中的值不能为负？

我刚刚尝试实现一个类，其中许多长度/计数属性等是uint而不是int 。然而，在这样做的时候，我注意到这样做实际上是痛苦的，就好像没有人真的想这样做。

几乎所有派生出整数types的东西都会返回一个int ，因此需要在几个点上进行转换。我想构造一个StringBuffer ，其缓冲区长度默认为该类中的一个字段。还需要演员阵容。

所以我想知道我是否应该回到这里int 。无论如何，我当然不会使用整个范围。我只是想，因为我在那里处理的东西根本不能是负面的（如果是的话，这将是一个错误），实际使用uint是一个不错的主意。

PS：我看到这个问题，这至less解释了为什么框架本身总是使用int但即使在自己的代码中，坚持使用uint实际上也很麻烦，这使得我认为它显然不是真正需要的。

虽然严格地说，你应该使用uint来存放非负整数的variables，但是你遇到了一些不可行的原因之一。

在这种情况下，我不认为减less与可执行文件相关的可读性是值得的。

我还会join其他答案，即使用uint作为公共字段的types，属性，方法，参数等，违反了公共语言规范的规则，并尽可能地避免。

负值通常用于表示错误情况，而操作的大小通常是由函数调用返回的; 因此负值可能因此表示错误而不诉诸于例外机制。

另外请注意，.NET通常build立在直接的C库上，因此继续这个约定是明智的。如果你需要更大的索引空间，你可以打破不同的错误信号机制的约定。

我个人的感觉是，你应该坚持int。为了回收一个数字范围，.NET不太可能让你继续使用，所以不必为每个属性访问添加一个转换。

使用int也有助于检测操作中的整数溢出。

国际海事组织，使用uint的缺点是它掩盖了错误条件。以下代码的等价物不太好：

 if (len < 0) terminate_program("length attained impossible value.");

当然你的程序不应该错误地计算任何东西，但是我觉得它们也应该被写成能够迅速地检测数字错误而不会传播。在2 ^ 31的MaxValue足够的情况下，我说使用int ，正确使用System.Diagnostics.Debug.Assert()和相应的错误检查，如上所示。

如果您确实使用uint使用它来checked以防止下溢并获得相同的结果。不过，我发现检查是有点难以适用于现有的代码，使用强制转换的目的。

如果你不需要，不要往上游游泳。不使用强制转换代码会使代码更具可读性。此外，如果你的可能的值适合一个int，那么使用int不是一个问题。

如果你害怕你可能溢出整数，那么通过一切手段..但不要过早优化。

我认为最小化强制types的可读性要高于使用int强度稍微高一点的风险。

如果你想检查一个值是肯定的，更好的方法可能只是通过使用断言（注意这只是一个debugging技术 – 你应该确保这从来没有发生在最终的代码）。

 using System.Diagnostics; ... Debug.Assert (i > 0);