为什么.NET在某些类中使用int而不是uint？
我总是碰到使用int代码，例如.Count等，甚至在框架类中，而不是uint 。
这是什么原因？
UInt32不符合CLS，因此它可能不适用于所有定位公共语言规范的语言。 Int32符合CLS标准，因此可以保证所有语言都存在。
在c中的int被专门定义为处理器的默认整数types，因此被认为是一般数值运算中最快的。
使用int的另一个原因是：
假设你有这样的for循环：
for (i = 0; i <= someList.Count - 1; i++) { // Stuff }
（尽pipe你可能不应该那样做）
显然，如果someList.Count是0和无符号，你会有一个问题。
如果这个数是真正的无符号的内在性质，那么我会声明它是一个无符号整数。 但是，如果我恰好在正数范围内使用了一个数字（暂时），那么我将其称为int。
主要原因是：
- 它避免了必须进行大量的types转换，因为大多数方法/函数被写入来获取int而不是unsigned int。
- 它消除了可能的截断警告。
- 你总是希望你可以分配一个负数的数字，你原来认为总是积极的。
只是想到几个简单的想法。
我曾经尝试过，要非常小心，select正确的未签名/签名，我终于意识到这并没有带来正面的好处。 这只是创造额外的工作。 那么为什么要通过混合和匹配使事情变得困难
UInt32不符合CLS。 http://msdn.microsoft.com/en-us/library/system.uint32.aspx
我认为多年来人们得出的结论是，使用无符号types实际上并没有提供太多好处。 更好的问题是，通过计数UInt32你会获得什么？
有些东西使用int，以便它们可以返回-1，就像它是“null”或类似的东西。 如果ComboBox没有select任何项目，它将返回-1的SelectedIndex。
如果带符号和无符号值的总和或乘积是一个足以容纳任一操作数的带符号types，并且两个无符号值之间的差值是足以容纳任何结果的有符号值，则无符号types的行为与整数类似。 因此，大量使用UInt32代码将经常需要将值计算为Int64 。 当操作数过大时，对有符号整数types的操作可能无法像整数一样操作，但是当操作数很小时，操作数会很明显。 即使在操作数很小的情况下，对无符号types的未扩展参数的操作也会造成问题。 鉴于UInt32 x; 例如，如果结果types是UInt32 ，并且不等式x<=0 || x-1>=0 ，则不等式x-1 < x对于x==0将失败。 如果结果types为Int32则x<=0 || x-1>=0对于较大的x值将失败。 只有在Int64types上执行操作时，才能保持不等式。
虽然定义无符号types的行为有别于整数算术，但是表示类似计数的值通常应该使用类似于整数的types – 一些无符号types通常不会这样做，小于基本整数types。
一些老图书馆，甚至InStr使用负数来表示特殊情况。 我相信无论是懒惰还是有负面的特殊价值。
