为什么有些类型没有文字修饰 [英] Why some types do not have literal modifiers
问题描述
例如，为什么长整型有文字修改，但短整型不？我指的是以下问题上这个网站： C＃编译器数量文字
在一般情况下，C＃似乎是一个很好的设计和一致的语言。有可能是一个强有力的理由对于一些类型的提供字面改性剂，但不是对所有。这是什么？
为什么长整型有文字修改，但短整型不？
问题是为什么C＃没有这个功能？在回答这个问题是永远不变的。功能默认情况下未实现; C＃不具有的功能，因为没有人设计，实施和运功能给客户。
由于缺乏一个功能并不需要理由。相反，所有的功能必须表明他们的收益大于成本是合理的。作为提议的功能的人，有责任对你描述为什么你认为该功能是难能可贵的;的责任不在我解释为什么它不是。
可能有强烈的理由对于一些类型的提供字面改性剂，但不是对所有。这是什么？
现在这是一个更加回答的问题。现在的问题是什么证明长字面后缀，这是为什么不也短了类似的文字后缀的理由？
整数，可用于各种目的。你可以把它们作为的算术号的。你可以把它们作为的位标志的集合的。您可以使用它们作为索引到数组。还有很多更特殊用途用法。但我认为这是公平地说，大部分的时间，整数用作算术数字。
绝大多数通过正常程序执行整数计算，涉及到远远的数字，远远超过32位有符号整数的范围小 - 大约+/-的两个十亿。和许多现代化的硬件只与32位整数打交道时是非常有效的。因此，它是有道理的，以数字的默认回复presentation要签名的32位整数。因此C＃的目的是使涉及32位有符号整数看起来完全正常的计算;当你说X = X + 1，即1被理解为是一个符号的32位整数，和赔率是好的，x是太，和总和的结果是太
如果计算是积分，但不放入一个32位的整数的范围？ 长的64位整数是一个明智的下一步了;他们也有很多的硬件高效，多头有应满足pretty多的人谁不这样做，涉及到非常大量的重型组合数学的需求范围。因此，它是有道理有一些方式源$ C $ C指定清晰，简洁，这种文字在这里被视为一个长整型。
互操作场景，或场景中，整数被用作比特字段，通常需要使用无符号整数的。再次，是有意义的有一种方法来清晰，简洁指定这个文字是为了被视为一个无符号整数。
所以，总结，当你看到1，赔率是好的，绝大多数的用户想要它的时候被用作一个32位有符号整数。下一个最有可能的情况是用户希望它是一个长整型或一个unsigned int或unsigned long类型。因此，有是每个这些案件简洁的后缀。
因此，该功能是有道理的。
这是为什么不是短裤的理由？
由于第一的在每一个方面，其中很短的是合法的，这已经是合法的使用文字整数的短X = 1;。是完全合法的;编译器意识到整数适合短，让你使用它。
二，算术从来没有在C＃的短裤完成。算术可以在整数，uints，多头和ulongs来完成，但算术的从不的短裤完成。短裤促进int和算术在整数做的，因为就像我以前说过，绝大多数的算术运算的融入一个int 的。绝大多数做的不的适合短。短算术可能是的慢的在其上的整数优化现代硬件和短算术不占用任何空间少;它会在芯片上的整数或多头工作要做。
您希望有一个长后缀告诉编译器这个算法需要多头做，而是一个短的后缀不告诉编译器这个算法需要的短裤做，因为这根本就不是C＃语言的一个特征开始。
用于提供长后缀和无符号的语法并不适用于短裤的原因。如果你认为有吸引力的利益特征，国家利益是什么。如果不能证明其成本效益，功能将不会在C＃实现的。
For example, why long int has a literal modifier, but short int does not? I am referring to the following question on this site: C# compiler number literals
In general, C# seems to be a very well designed and consistent language. Probably there is a strong reason to provide literal modifiers for some types, but not for all. What is it?
解决方案Why long int has a literal modifier, but short int does not?
The question is "why does C# not have this feature?" The answer to that question is always the same. Features are unimplemented by default; C# does not have that feature because no one designed, implemented and shipped the feature to customers.
The absence of a feature does not need justification. Rather, all features must be justified by showing that their benefits outweigh their costs. As the person proposing the feature, the onus is on you to describe why you think the feature is valuable; the onus is not on me to explain why it is not.
Probably there is a strong reason to provide literal modifiers for some types, but not for all. What is it?
Now that is a more answerable question. Now the question is "what justifies the literal suffix on long, and why is that not also a justification for a similar literal suffix on short?"
Integers can be used for a variety of purposes. You can use them as arithmetic numbers. You can use them as collections of bit flags. You can use them as indices into arrays. And there are lots of more special-purpose usages. But I think it is fair to say that most of the time, integers are used as arithmetical numbers.
The vast majority of calculations performed in integers by normal programs involve numbers that are far, far smaller than the range of a 32 bit signed integer -- roughly +/- two billion. And lots of modern hardware is extremely efficient when dealing solely with 32 bit integers. It therefore makes sense to make the default representation of numbers to be signed 32 bit integers. C# is therefore designed to make calculations involving 32 bit signed integers look perfectly normal; when you say "x = x + 1" that "1" is understood to be a signed 32 bit integer, and odds are good that x is too, and the result of the sum is too.
What if the calculation is integral but does not fit into the range of a 32 bit integer? "long" 64 bit integers are a sensible next step up; they are also efficient on a lot of hardware and longs have a range that should satisfy the needs of pretty much anyone who isn't doing heavy-duty combinatorics that involve extremely large numbers. It therefore makes sense to have some way to specify clearly and concisely in source code that this literal here is to be treated as a long integer.
Interop scenarios, or scenarios in which integers are used as bit fields, often require the use of unsigned integers. Again, it makes sense to have a way to clearly and concisely specify that this literal is intended to be treated as an unsigned integer.
So, summing up, when you see "1", odds are good that the vast majority of the time the user intends it to be used as a 32 bit signed integer. The next most likely cases are that the user intends it to be a long integer or an unsigned int or unsigned long. Therefore there are concise suffixes for each of those cases.
Thus, the feature is justified.
Why is that not a justification for shorts?
Because first, in every context in which a short is legal, it is already legal to use an integer literal. "short x = 1;" is perfectly legal; the compiler realizes that the integer fits into a short and lets you use it.
Second, arithmetic is never done in shorts in C#. Arithmetic can be done in ints, uints, longs and ulongs, but arithmetic is never done in shorts. Shorts promote to int and the arithmetic is done in ints, because like I said before, the vast majority of arithmetic calculations fit into an int. The vast majority do not fit into a short. Short arithmetic is possibly slower on modern hardware which is optimized for ints, and short arithmetic does not take up any less space; it's going to be done in ints or longs on the chip.
You want a "long" suffix to tell the compiler "this arithmetic needs to be done in longs" but a "short" suffix doesn't tell the compiler "this arithmetic needs to be done in shorts" because that's simply not a feature of the C# language to begin with.
The reasons for providing a long suffix and an unsigned syntax do not apply to shorts. If you think there is a compelling benefit to the feature, state what the benefit is. Without a benefit to justify its costs, the feature will not be implemented in C#.
这篇关于为什么有些类型没有文字修饰的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
