例如,为什么long int有一个文字修饰符,但是short int不是？我指的是这个网站上的以下问题:C#编译器编号文字
通常,C#似乎是一种设计良好且一致的语言.可能有一个强有力的理由为某些类型提供文字修饰符,但不是所有类型.它是什么？
Eri*_*ert 36
为什么long int有一个文字修饰符,但是short int不是？
问题是"为什么C#没有这个功能？" 这个问题的答案总是一样的.默认情况下,功能未实现; C#没有该功能,因为没有人设计,实现并将该功能发送给客户.
没有特征不需要证明理由.相反,所有功能必须通过证明其好处超过其成本来证明.作为提出该功能的人,您有责任描述您认为该功能有价值的原因; 我不能解释为什么不是.
可能有一个强有力的理由为某些类型提供文字修饰符,但不是所有类型.它是什么？
现在这是一个更负责任的问题.现在的问题是"长期以来文字后缀的合理性,为什么这也不是短文中类似文字后缀的理由？"
整数可用于各种目的.您可以将它们用作算术数字.您可以将它们用作位标志的集合.您可以将它们用作数组的索引.还有很多特殊用途.但我认为可以公平地说,大多数时候,整数被用作算术数字.
普通程序以整数执行的绝大多数计算涉及的数字远远小于32位有符号整数的范围 - 大约+/- 20亿.在处理32位整数时,许多现代硬件都非常高效.因此,使数字的默认表示符号为32位整数是有意义的.因此,C#旨在使涉及32位有符号整数的计算看起来完全正常; 当你说"x = x + 1"时,"1"被理解为带符号的32位整数,并且x也是好的几率,并且总和的结果也是如此.
如果计算是整数但不适合32位整数的范围怎么办？"长"64位整数是明智的下一步; 它们在许多硬件上也很有效,并且长期有一个范围可以满足几乎所有没有进行涉及极大数量的重型组合的人的需求.因此,有一些方法可以在源代码中明确而简洁地指定此文字在这里被视为一个长整数.
互操作方案或将整数用作位字段的方案通常需要使用无符号整数.同样,有一种方法可以清楚简明地指定此文字旨在被视为无符号整数.
总而言之,当你看到"1"时,用户希望将它用作32位有符号整数的绝大部分时间都是好的.接下来最可能的情况是用户希望它是长整数或无符号整数或无符号整数.因此,每种情况都有简明的后缀.
因此,该特征是合理的.
为什么这不是短裤的理由？
因为首先,在短语合法的每个环境中,使用整数文字已经是合法的."短x = 1;" 完全合法; 编译器意识到整数适合短路并让你使用它.
其次,算术永远不会在C#中做空.算术可以用ints,uints,longs和ulongs来完成,但算术永远不会在短时间内完成.短程提升为int,算术以整数形式完成,因为正如我之前所说,绝大多数算术计算都适合于int.绝大多数都不适合做空.在针对整数优化的现代硬件上,短算术可能较慢,而短算术不会占用更少的空间; 它将在芯片上以整数或多头完成.
你想要一个"长"后缀来告诉编译器"这个算法需要在longs中完成",但是"short"后缀并不能告诉编译器"这个算法需要在短路中完成",因为这根本不是首先是C#语言.
提供长后缀和无符号语法的原因不适用于短路.如果您认为该功能有令人信服的好处,请说明好处是什么.没有任何好处来证明其成本,该功能将不会在C#中实现.
根据MSDN:
short x = 32767;
在前面的声明中,整数文字32767被隐式地从int转换为short.如果整数文字不适合短存储位置,则会发生编译错误.
所以这是一个编译时功能.short没有后缀,因为它永远不需要.
相关问题可能是:为什么long,float并且decimal确实有后缀？
简短的回答是,i + 1并且i + 1L可以产生不同的值,因此具有不同的类型.
但是不存在"短算术"这样的东西, 在计算中使用时short总是转换为int值.