為什么有些類型沒有文字修飾符

Question

例如，為什么long int有一個文字修飾符，但是short int不是？ 我指的是這個網站上的以下問題： C＃編譯器編號文字

通常，C＃似乎是一種設計良好且一致的語言。 可能有一個強有力的理由為某些類型提供文字修飾符，但不是所有類型。 它是什么？

Answer 1

為什么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＃中實現。

Answer 2

根據MSDN ：

short x = 32767;

在前面的聲明中，整數文字32767被隱式地從int轉換為short。 如果整數文字不適合短存儲位置，則會發生編譯錯誤。

所以這是一個編譯時功能。 short沒有后綴，因為它永遠不需要。

相關問題可能是：為什么long ， float和decimal確實有后綴？
簡短的回答是i + 1和i + 1L可以產生不同的值，因此具有不同的類型。

但是不存在“短算術”這樣的東西，在計算中使用時， short值總是轉換為int 。

Answer 3

正如埃里克在評論中指出的那樣，我的答案下面沒有意義。 我認為說無法在C＃中表達一個簡短的字面並且無法在IL中表達一個簡短的文字有一個共同的原因（缺乏一個令人信服的理由來說明這個特征。）VB.Net顯然有一個簡短的說法。文字說明符，這很有趣（為了向后兼容VB語法？）無論如何，我在這里留下了答案，因為一些信息可能很有趣，即使推理不正確。

---

沒有短文字，因為實際上沒有任何方法可以在IL中加載短文字，IL是CLR使用的基礎語言。 這是因為所有“短”類型（任何小於int的類型）在加載到操作堆棧時都會隱式擴展為int。 有符號和無符號同樣是操作問題，並且實際上沒有與操作堆棧上的活動數字“存儲”。 當你想在操作堆棧中將一個數字存儲到一個內存位置時，'short'類型才會發揮作用，因此有IL操作轉換為各種'short'類型（盡管它實際上仍然將數字擴展回int轉換后;它只是確保該值適合存儲到“短”類型的字段中。）

另一方面，長類型具有文字說明符，因為它們在操作堆棧上被區別對待。 有一個單獨的Ldc_I8指令用於加載常量長值。 還有Ldc_R4（因此為什么你需要浮點數'f'）和Ldc_R8（如果你使用沒有說明符的十進制數字，C＃選擇它作為默認值。）十進制是一種特殊情況，因為它實際上不是IL中的原始類型; 它只是在C＃中有一個內置的常量說明符'm'，它編譯成一個構造函數調用。

至於為什么沒有特殊的短操作（以及相應的短文字），這可能是因為大多數當前的CPU架構不能使用小於32位的寄存器，因此在CPU級別上沒有區別值得利用。 您可以通過允許“短”加載IL操作碼來節省代碼大小（以IL的字節數表示），但代價是抖動的額外復雜性; 保存的代碼空間可能不值得。

Answer 4

由於short可以隱式轉換為int ， long ， float ， double或decimal ; 不需要文字修飾符。

考慮：

void method(int a) {}
void method2()
{
    short a = 4;
    method(a); // no problems
}

你可能會注意到char和byte也有文字修飾符，可能是同樣的原因。

From    To
sbyte   short, int, long, float, double, or decimal
byte    short, ushort, int, uint, long, ulong, float, double, or decimal
short   int, long, float, double, or decimal
ushort  int, uint, long, ulong, float, double, or decimal
int     long, float, double, or decimal
uint    long, ulong, float, double, or decimal
long    float, double, or decimal
char    ushort, int, uint, long, ulong, float, double, or decimal
float   double
ulong   float, double, or decimal

Answer 5

如果聲明文字短並使其大於Short.MaxValue則會發生編譯器錯誤，否則文字將是短的。

Answer 6

我“在短時間內工作”的時間是存儲在數據庫中的值。

它們是正整數值，很少會超過10到20.（一個字節或一個字節就足夠了，但是如果代碼以稍微不同的方式重復使用，我認為有點過分會讓我后悔自己的選擇）

該字段用於讓用戶對表中的記錄進行排序。 此表提供按“時間”排序的下拉列表或單選按鈕列表（第一步，第二步，......）。

對C＃不熟悉（並且在計算字節數時要記得很重要）我認為它會更有效率。 我不對數值做數學。 我只是對它們進行排序（並在記錄之間進行交換）。 到目前為止唯一的數學是“MaxInUse”+1（對於新記錄），這是一個特例“++ MaxInUse”。 這很好，因為缺少文字意味着“s = s + 2”必須是“s =（Int16）（s + 2）”。

現在我看到C＃與其他整數一起工作有多煩人，我希望加入現代世界並浪費字節，只是為了讓編譯器滿意。

但是，在我們的十大編程目標中，不應該“讓編譯器滿意”排名第65位嗎？

讓編譯器抱怨將整數“2”添加到任何INTEGER類型中是否有利於它？ 它應該抱怨“s = 123456”，但這是一個不同的情況。

如果有人必須處理數學和短褲，我建議你制作自己的文字。 （你需要多少？）

short s1= 1, s2 = 2, s123 = 123;

然后s = s + s2只是有點惱人（對於那些追隨你的人而感到困惑）。