为什么Count不是无符号整数?

Inn*_*nno 47 .net c#

可能重复:
为什么.NET在某些类中使用int而不是uint?
为什么Array.Length是int,而不是uint

我一直想知道为什么.Count不是无符号整数而不是有符号整数?

例如,拿ListView.SelectedItems.Count.元素的数量不能少于0,那么为什么它是一个有符号的int?

如果我尝试测试是否有选择的元素,我想测试

 if (ListView.SelectedItems.Count == 0) {}
Run Code Online (Sandbox Code Playgroud)

但因为它是有符号整数,我必须测试

 if (ListView.SelectedItems.Count <= 0) {}
Run Code Online (Sandbox Code Playgroud)

或者有什么情况.Count可能<0?

Phi*_*ert 54

无符号整数不符合CLS(通用语言规范)

有关符合CLS的代码的更多信息,请参阅此链接:

http://msdn.microsoft.com/en-us/library/bhc3fa7f.aspx

  • 虽然这回答了这封信的问题,但它没有解释.也许问题应该是,"*为什么*不符合CLS?"这确实是一个奇怪的决定. (14认同)
  • uint不符合CLS的问题是一个单独问题的主题,这里已经提到了这个问题:http://stackoverflow.com/questions/6325/why-are-unsigned-ints-not-cls-compliant (13认同)

nan*_*nan 6

Mabye因为uint数据类型不是CLS(通用语言规范)的一部分,因为并非所有.Net语言都支持它.

这是关于数组的非常相似的线程:

为什么Array.Length是int,而不是uint


Ian*_*ose 5

让我们从实际角度来看待这个问题.

无论好坏,signed ints都是.NET中使用的正常类型int.int在C和C++中使用signed s 也是正常的.因此,除非有充分的理由,否则大多数变量都被声明为int而不是无符号int.

在无符号int和有符号之间进行转换会产生int问题,但并不总是安全的.

在32位系统上,集合不可能有任何接近2 ^^ 32个项目,所以签名int在所有情况下都足够大.

在64位系统上,unsigned int不会带来太多收益,在大多数情况下,signed int仍然足够大,否则你需要使用64位int. (我希望标准集合中没有一个能够很好地应对64系统上2 ^^ 31项附近的任何地方!)

因此,如果使用unsigned int没有明显的优势,为什么要使用unsigned int

  • 我看到一个明显的优势:当有人犯错时,例如`(Names.Count <0)`(而不是`(Names.Count> 0)`)编译器可以发出警告.我认为警告用户犯错误是编译器的一项非常重要的任务,任何能够更容易发现错误的语言都比竞争对手更具优势.事实上,这就是我首先选择编译语言的原因. (6认同)
  • 这个解释站不住脚。列表/字典/等中不能有负数的项目,因此将 Count 设为 int 是愚蠢的。 (2认同)

Jon*_*nna 5

  1. 它不符合 CLS,主要是为了允许不同语言提供更广泛的支持。

  2. 有符号 int 可以轻松地从使用指针算术的 C 或 C++ 移植代码。

  3. 计数可以是表达式的一部分,其中总体值可以为负数。特别是,计数与索引有直接关系,其中有效索引始终在 [0, Count - 1] 范围内,但某些二分搜索方法(包括 BCL 提供的方法)等使用负结果来反映位置应插入新项目以维持秩序的位置。