【发布时间】:2010-09-05 14:24:25
【问题描述】:
为什么无符号整数不符合 CLS?
我开始认为类型规范只是为了性能而不是正确性。
【问题讨论】:
标签: c# .net unsigned-integer cls-compliant
为什么无符号整数不符合 CLS?
我开始认为类型规范只是为了性能而不是正确性。
【问题讨论】:
标签: c# .net unsigned-integer cls-compliant
并非所有语言都有无符号整数的概念。例如,VB 6 没有无符号整数的概念,我怀疑这促使 VB7/7.1 的设计者决定不实现(它现在在 VB8 中实现)。
引用:
http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx
CLS 的设计足够大,可以包含语言 开发人员通常需要的结构,但足够小 大多数语言都能够支持它。此外,任何语言 无法快速验证类型安全性的构造 的代码从 CLS 中排除,以便所有符合 CLS 的语言 如果他们选择这样做,可以生成可验证的代码。
更新:几年前我确实想知道这一点,虽然我不明白为什么 UInt 不能进行类型安全验证,但我猜 CLS 家伙必须在某个地方有一个截止点,什么会是支持的值类型的基线最小数量。此外,当您考虑到越来越多的语言被移植到 CLR 的长期时,如果绝对没有概念,为什么还要强迫他们实现无符号整数以获得 CLS 合规性?
【讨论】:
我怀疑,问题的一部分围绕着这样一个事实,即 C 中的无符号整数类型必须表现为抽象代数环的成员而不是数字 [这意味着,例如,如果一个无符号 16 位整数变量等于 0,减少它需要产生 65,535,如果它等于 65,535,那么增加它需要产生零。] 有时这种行为非常有用,但数字类型表现出这样行为可能违背了某些语言的精神。我猜想省略无符号类型的决定可能早于支持检查和未检查数字上下文的决定。就个人而言,我希望无符号数和代数环有单独的整数类型;将一元减号运算符应用于无符号 32 位数字应产生 64 位有符号结果[否定除零以外的任何内容将产生负数],但将一元减号应用于环类型应产生该环内的加法逆。
无论如何,无符号整数不符合 CLS 的原因是 Microsoft 决定语言不必支持无符号整数即可被视为“与 CLS 兼容”。
【讨论】:
无符号整数不符合 CLS,因为它们在某些语言之间不可互操作。
【讨论】:
Unsigned int 在现实生活中并没有给你带来太多好处,但是拥有超过 1 种类型的 int 会给你带来痛苦,所以很多语言都只有 singed int。
符合 CLS 的目的是允许从多种语言中使用一个类……
请记住,没有人让您符合 CLS。
您仍然可以在在方法中使用无符号整数,或作为私有方法的参数,因为它只是符合 CLS 限制的公共 API。
【讨论】: