作为索引的无符号数字与有符号数字
在 .Net 中使用带符号数字作为索引的理由是什么？
在 Python 中，您可以通过发送负数从数组末尾开始索引，但在 .Net 中并非如此。 .Net 稍后添加这样的功能并不容易，因为它可能会在索引上使用特殊规则（是的，一个坏主意，但我猜它会发生）来破坏其他代码。
并不是说我曾经需要索引大小超过 2,147,483,647 的数组，但我真的无法理解为什么他们选择有符号数字。
难道是因为在代码中使用带符号的数字更正常吗？
编辑：我刚刚找到这些链接：
Edit2：好吧，Matthew Flaschen 发布的线程中还有其他一些很好的理由：
- 历史原因，因为它是一种类似 c 的语言
- 与 c 的互操作
Whats the rationale for using signed numbers as indexes in .Net?
In Python, you can index from the end of an array by sending negative numbers, but this is not the case in .Net.
It's not easy for .Net to add such a feature later as it could break other code perhaps using special rules (yeah, a bad idea, but I guess it happens) on indexing.
Not that I have ever have needed to index arrays over 2,147,483,647 in size, but I really cannot understand why they choose signed numbers.
Can it be because it's more normal to use signed numbers in code?
Edit: I just found these links:
The perils of unsigned iteration in C/C++
Signed word lengths and indexes
Edit2: Ok, a couple of other good reasons from the thread Matthew Flaschen posted:
- Historical reasons as it's a c-like language
- Interop with c
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这可能与使用低于 0 的值作为无效索引的长期传统有关。如果未找到该元素，诸如 String.IndexOf 之类的方法将返回 -1。因此，返回值必须有符号。如果索引使用者需要无符号值，则必须 a) 检查并 b) 强制转换该值才能使用它。对于签名索引，您只需要检查即可。
It may be to the long tradition of using a value below 0 as an invalid index. Methods like String.IndexOf return -1 if the element is not found. Therefore, the return value must be signed. If index-consumers would require unsigned values, you would have to a) check and b) cast the value to use it. With signed indices, you just need the check.
当然是为了简单起见。您是否喜欢使用无符号整数进行大小算术麻烦？
For simplicity of course. Do you like trouble doing size arithmetic with unsigned ints?
Unsigned 不符合 CLS。
Unsigned isn't CLS compliant.
当用较小的数字组成较大的数字时，无符号数字的主要用途就出现了，反之亦然。例如，如果从连接接收到四个无符号字节，并希望将它们的值作为一个整体视为 32 位整数，那么使用无符号类型意味着我们可以简单地说：
相比之下，如果字节是有符号的，则像上面这样的表达式会更复杂。
我不确定我是否真的看到当今设计的语言有任何理由不包含比最长有符号整数类型短的所有类型的无符号版本，其语义是所有整数（意味着离散数量数字，而不是任何特定类型） ）完全适合最大有符号类型的操作将默认执行就像它们正在对该类型进行操作一样。包含最大有符号类型的无符号版本将使语言规范变得复杂（因为必须指定哪些操作必须适合有符号类型的范围，以及哪些操作必须适合无符号类型的范围），但否则应该有设计一种语言，即使
unsigned2大于unsigned1<，if (unsigned1 - unsigned2 > unsigned3)也能产生“数字正确”的结果，这是没有问题的。 /code> [如果想要无符号环绕，则可以显式指定if ((Uint32)(unsigned1 - unsigned2) > unsigned3)]。一种指定这种行为的语言肯定会比 C（考虑到其历史，这是合理的）、C# 或 vb.net 中存在的混乱情况做出重大改进。The primary usefulness of unsigned numbers arises when composing larger numbers from smaller ones and vice versa. For example, if one receives four unsigned bytes from a connection and wishes to regard their value, taken as a whole, as a 32-bit integer, using unsigned types means one can simply say:
By contrast, if the bytes were signed, an expression like the above would be more complicated.
I'm not sure I really see any reason for a language designed nowadays not to include unsigned versions of all types shorter than the longest signed integer type, with the semantics that all integer (meaning discrete-quantity-numerics, rather than any particular type) operations which will fit entirely within the largest signed type will by default be performed as though they were operating upon that type. Including an unsigned version of the largest signed type would complicate the language specification (since one would have to specify which operations must fit within range of the signed type, and which operations must fit within range of the unsigned type), but otherwise there should be no problem designing a language so that
if (unsigned1 - unsigned2 > unsigned3)would yield a "numerically-correct" result even whenunsigned2is greater thanunsigned1[if one wants unsigned wraparound, one would explicitly specifyif ((Uint32)(unsigned1 - unsigned2) > unsigned3)]. A language which specified such behavior would certainly be a big improvement over the mess that exist in C (justifiable, given its history), C#, or vb.net.