为什么无符号整型不符合 CLS？

小开

最佳答案

并非所有语言都有无符号整型的概念。例如，VB6没有无符号整数的概念，我怀疑是这个概念促使 VB7/7.1的设计者决定不去实现它(它现在已经在 VB8中实现了)。

引用如下:

Http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

CLS 被设计得足够大，可以包含语言开发人员通常需要的结构，但是这些结构足够小大多数语言都能够支持它。此外，任何语言构造，使得无法迅速验证类型的安全性的代码被排除在 CLS 之外，以便所有符合 CLS 的语言可以产生可验证的代码，如果他们选择这样做。

更新: 几年前我确实对此感到疑惑，虽然我不明白为什么 UInt 不能验证类型安全，但我猜测 CLS 的家伙必须有一个截止点，那就是支持的基准最小值类型数量。另外，考虑到越来越多的语言被移植到 CLR 的长期情况，如果根本没有概念，为什么要强迫它们实现无符号整型来获得 CLS 遵从性呢？

小开

无符号整数不符合 CLS，因为它们在某些语言之间不能互操作。

小开

无符号整型在现实生活中并没有多大帮助，但是有多于一种类型的整型会给你带来痛苦，所以很多语言只有有符号整型。

CLS 兼容旨在允许使用来自多种语言的类..。

Remember that no one makes you be CLS compliant.

您仍然可以使用无符号整数内心作为方法，或者作为 二等兵方法的 parms，因为它只是符合 CLS 的公共 API。

小开

我怀疑，这个问题的部分原因在于，C 语言中的无符号整数类型需要作为抽象代数环的成员而不是作为数字来运行[这意味着，例如，如果一个无符号16位整数变量等于零，那么递减它就是 required，得到65,535，如果它等于65,535，那么递增它就得到零。]有时候这种行为是非常有用的，但是数字类型表现出来的这种行为可能违背了某些语言的精神。我推测，省略无符号类型的决定可能早于同时支持检查和未检查数字上下文的决定。就个人而言，我希望对于无符号数和代数环有单独的整数类型，对无符号32位数应用一元减号运算符应该会得到一个64位有符号结果[否定除零以外的任何值都会得到一个负数] ，但对环类型应用一元减号应该会得到环内的加法逆元。

无论如何，无符号整数不符合 CLS 的原因是微软决定语言不必支持无符号整数才能被认为是“ CLS 兼容的”。