为啥 unsigned int 不符合 CLS？

Posted 2023-03-31

【中文标题】为啥 unsigned int 不符合 CLS？

【英文标题】：Why are unsigned int's not CLS compliant?为什么 unsigned int 不符合 CLS？

【发布时间】：2010-09-05 14:24:25

【问题描述】：

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

我开始认为类型规范只是为了性能而不是正确性。

【参考方案1】：

并非所有语言都有无符号整数的概念。例如，VB 6 没有无符号整数的概念，我怀疑这促使 VB7/7.1 的设计者决定不实现（它现在在 VB8 中实现）。

引用：

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

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

更新：几年前我确实想知道这一点，虽然我不明白为什么 UInt 不能进行类型安全验证，但我猜 CLS 家伙必须在某个地方有一个截止点，什么会是支持的值类型的基线最小数量。此外，当您考虑到越来越多的语言被移植到 CLR 的长期时，如果绝对没有概念，为什么还要强迫他们实现无符号整数以获得 CLS 合规性？

【讨论】：

@Kevin：我只是想知道这个话题。你的回答似乎合乎逻辑。我只是喜欢思考这个话题。我认为类似 Pascal 的类型没有进入 CLR 是一种耻辱。但是您关于其他语言的论点：这并没有阻止 IronPython 在强静态类型 CLR 中使用强动态类型 (DLR)？

@doekman：虽然 IronPython 和 IronRuby 证明 CLR 可以提供一个平台，您可以在该平台上构建动态类型语言，但 CLS 的目标是提供一组超越语言功能和让他们能够成功和安全地进行互操作。我不认为一种语言在添加深度学习功能方面能做什么与应该进入 CLS/CTS 的内容直接相关。

据我了解，CLR 有一个 32 位整数基元类型，它有单独的指令用于带溢出检查的有符号加法、带溢出检查的无符号加法和符号不可知加法 mod 2^32，等等。;当被要求将对象引用转换为 32 位整数原语时，CLR 既不知道也不关心使用该数字的代码期望它是有符号的还是无符号的。编译器认为数字是有符号还是无符号通常会影响编译器为其操作生成的指令，但这是一种语言问题，而不是 CLR 问题。

【参考方案2】：

我怀疑，问题的一部分围绕着这样一个事实，即 C 中的无符号整数类型必须表现为抽象代数环的成员而不是数字 [这意味着，例如，如果一个无符号 16 位整数变量等于 0，减少它需要产生 65,535，如果它等于 65,535，那么增加它需要产生零。] 有时这种行为非常有用，但数字类型表现出这样行为可能违背了某些语言的精神。我猜想省略无符号类型的决定可能早于支持检查和未检查数字上下文的决定。就个人而言，我希望无符号数和代数环有单独的整数类型；将一元减号运算符应用于无符号 32 位数字应产生 64 位有符号结果[否定除零以外的任何内容将产生负数]，但将一元减号应用于环类型应产生该环内的加法逆。

无论如何，无符号整数不符合 CLS 的原因是 Microsoft 决定语言不必支持无符号整数即可被视为“与 CLS 兼容”。

【讨论】：

从数学角度很好的解释！

【参考方案3】：

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

【参考方案4】：

Unsigned int 在现实生活中并没有给你带来太多好处，但是拥有超过 1 种类型的 int 会给你带来痛苦，所以很多语言都只有 singed int。

符合 CLS 的目的是允许从多种语言中使用一个类……

请记住，没有人让您符合 CLS。

您仍然可以在在方法中使用无符号整数，或作为私有方法的参数，因为它只是符合 CLS 限制的公共 API。

【讨论】：

如果你在做任何位运算，它们是非常重要的。

@nicodemus13 您最后一次看到在其问题域中具有按位运算的业务管理系统是什么时候？ （例如 VB.NET 程序员编写的那种软件）

任何带有校验和的东西都将使用按位算术，这是相当普遍的，我觉得把所有其他语言都拖下来似乎很奇怪，因为 VB 不支持无符号整数。 .NET 也应该是通用的，不仅适用于 LOB 应用程序的 VB 编写者。当你说 '1 type of int' 时，你不认为拥有 byte、short、int、long 也是一种痛苦吗？我不太明白为什么签名会更尴尬。