implicitly convert type ”int” to ”short”的原因與解決方案

看看下面的代碼: 複製代碼 代碼如下:sbyte sba, sbb,sbv;
sba = 1;
sbb = 2;
sbv = sba + sbb;

byte ba, bb, bv;
ba = 1;
bb = 2;
bv = ba + bb;

short sa, sb, sv;
sa = 1;
sb = 2;
sv = sa + sb;

ushort usa, usb, usv;
usa = 1;
usb = 2;
usv = usa + usb;

你覺得這段代碼能否正確執行?結果會怎樣? 結果就是：這段代碼會出現編譯錯誤.
正確的代碼應該如下: 複製代碼 代碼如下:sbyte sba, sbb,sbv;
sba = 1;
sbb = 2;
sbv = (sbyte)(sba + sbb);

byte ba, bb, bv;
ba = 1;
bb = 2;
bv = (byte)(ba + bb);

short sa, sb, sv;
sa = 1;
sb = 2;
sv = (short)(sa + sb);

ushort usa, usb, usv;
usa = 1;
usb = 2;
usv = (ushort)(usa + usb);

MessageBox.Show(string.Format("{0},{1},{2},{3}", sbv, bv, sv, usv));

這是什麼原因呢?
其實CLR底層只支援 int,int64,native int, float , double幾種資料類型. 像上面的sbyte,byte,short,ushort, clr底層是不支援的,在底層這些類型是用int表示的. CLR的堆棧中壓入的數字,最小是4位元組,小於4位元組的會根據其類型進行符號擴充或者0擴充為4位元組int型. 這樣四則運算的結果也是int型,最後再賦值需要進行強制類型轉換. 分析一下編譯後的IL代碼就清楚了.

下面這個代碼為什麼能編譯呢?

複製代碼 代碼如下:short sb;
sb=2;
sb += 1;

其實編譯後的IL代碼中最後賦值也包含了類型轉換操作.

看下更加詳細的解釋：複製代碼 代碼如下:short s=0;
s = s + 1; //報錯，右端是複雜運算式，1被解釋成int
s+=1; //不報錯，1被解釋成short, 請看下面的解釋
s += 32768; //報錯，顯然32768是不能解釋成short的，只能解釋成int
s+=(s+1); //報錯，右端是複雜運算式，1被解釋成int

從上面可以看出一個規則，那就是，複雜運算式計算中的隱式良性類型轉換，一概預設直接解釋或轉換成4位元組對齊的CLS相容類型，如int/long，理由很簡單：既省了麻煩，又能保證效能(不僅有運行效率時的考慮，而且還有代碼產生的考慮，因此這種考慮是一步到位的)，例如，s=s+1中的1，被解釋成了int，而不是short，這是合理的。但如果不是複雜運算式，而僅僅只是一個簡單的常數量的話，編譯器在parse時便不會遵循"4位元組對齊的CLS相容類型"，它將根據其他部分來自動判別最適合的類型（這種做法也是合理的，因為此時仍處於parse階段，迅速判斷類型是否相容才是第一要務，效能不效能、對不對齊是次要問題，所以，此時對數字常量的類型解釋也用不著一步到位，遵循最快最省事原則即可...），比方說s+=1和s+=32768這兩個例子，前者1被解釋成short，所以合法，後者32768將被迫解釋成int，左右式類型不相容，所以出錯。同理，上述解釋也適用於s+=(s+1)這個例子：(s+1)是複雜運算式，不是簡單數字常量，所以被解釋成(int)s+(int)1，而不是(short)s+(short)1，從而報錯。

請注意上述解釋主要針對parse階段。實際上，到了代碼產生階段，出於效能等目的，類型可能還會得到進一步提升，如s+=1這個例子，實際上在IL代碼產生階段，這個parse階段識別出來的(short)1最終被提升為了(int)1，這應該便是瑞克觀察到的IL參數4位元組對齊的現象了。其實，為避免混淆，我覺得一般使用者理解到parser層面便足矣，因為類型的判別和相容性檢查在代碼產生階段已經不是關鍵問題了，不過當然，只要是良性型別提升，無論哪個階段都是可以做的，甚至，只要在parse階段編譯器已經獲得了正確的類型資訊，那麼，在代碼產生階段對變數再進行非良性的類型轉換，這也是有保障的設計行為。至此，我相信解釋應該完整了...