|
|
復(fù)制代碼 代碼如下:
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;
你覺(jué)得這段代碼能否正確執(zhí)行?結(jié)果會(huì)怎樣? 結(jié)果就是：這段代碼會(huì)出現(xiàn)編譯錯(cuò)誤.
正確的代碼應(yīng)該如下:
復(fù)制代碼 代碼如下:
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));
這是什么原因呢?
其實(shí)CLR底層只支持 int,int64,native int, float , double幾種數(shù)據(jù)類(lèi)型. 像上面的sbyte,byte,short,ushort, clr底層是不支持的,在底層這些類(lèi)型是用int表示的. CLR的堆棧中壓入的數(shù)字,最小是4字節(jié),小于4字節(jié)的會(huì)根據(jù)其類(lèi)型進(jìn)行符號(hào)擴(kuò)展或者0擴(kuò)展為4字節(jié)int型. 這樣四則運(yùn)算的結(jié)果也是int型,最后再賦值需要進(jìn)行強(qiáng)制類(lèi)型轉(zhuǎn)換. 分析一下編譯后的IL代碼就清楚了.
下面這個(gè)代碼為什么能編譯呢?
復(fù)制代碼 代碼如下:
short sb;
sb=2;
sb += 1;
其實(shí)編譯后的IL代碼中最后賦值也包含了類(lèi)型轉(zhuǎn)換操作.
看下更加詳細(xì)的解釋：
復(fù)制代碼 代碼如下:
short s=0;
s = s + 1; //報(bào)錯(cuò)，右端是復(fù)雜表達(dá)式，1被解釋成int
s+=1; //不報(bào)錯(cuò)，1被解釋成short, 請(qǐng)看下面的解釋
s += 32768; //報(bào)錯(cuò)，顯然32768是不能解釋成short的，只能解釋成int
s+=(s+1); //報(bào)錯(cuò)，右端是復(fù)雜表達(dá)式，1被解釋成int
從上面可以看出一個(gè)規(guī)則，那就是，復(fù)雜表達(dá)式計(jì)算中的隱式良性類(lèi)型轉(zhuǎn)換，一概默認(rèn)直接解釋或轉(zhuǎn)換成4字節(jié)對(duì)齊的CLS兼容類(lèi)型，如int/long，理由很簡(jiǎn)單：既省了麻煩，又能保證性能(不僅有運(yùn)行效率時(shí)的考慮，而且還有代碼生成的考慮，因此這種考慮是一步到位的)，例如，s=s+1中的1，被解釋成了int，而不是short，這是合理的。但如果不是復(fù)雜表達(dá)式，而僅僅只是一個(gè)簡(jiǎn)單的常數(shù)量的話，編譯器在parse時(shí)便不會(huì)遵循"4字節(jié)對(duì)齊的CLS兼容類(lèi)型"，它將根據(jù)其他部分來(lái)自動(dòng)判別最適合的類(lèi)型（這種做法也是合理的，因?yàn)榇藭r(shí)仍處于parse階段，迅速判斷類(lèi)型是否兼容才是第一要?jiǎng)?wù)，性能不性能、對(duì)不對(duì)齊是次要問(wèn)題，所以，此時(shí)對(duì)數(shù)字常量的類(lèi)型解釋也用不著一步到位，遵循最快最省事原則即可...），比方說(shuō)s+=1和s+=32768這兩個(gè)例子，前者1被解釋成short，所以合法，后者32768將被迫解釋成int，左右式類(lèi)型不兼容，所以出錯(cuò)。同理，上述解釋也適用于s+=(s+1)這個(gè)例子：(s+1)是復(fù)雜表達(dá)式，不是簡(jiǎn)單數(shù)字常量，所以被解釋成(int)s+(int)1，而不是(short)s+(short)1，從而報(bào)錯(cuò)。
請(qǐng)注意上述解釋主要針對(duì)parse階段。實(shí)際上，到了代碼生成階段，出于性能等目的，類(lèi)型可能還會(huì)得到進(jìn)一步提升，如s+=1這個(gè)例子，實(shí)際上在IL代碼生成階段，這個(gè)parse階段識(shí)別出來(lái)的(short)1最終被提升為了(int)1，這應(yīng)該便是瑞克觀察到的IL參數(shù)4字節(jié)對(duì)齊的現(xiàn)象了。其實(shí)，為避免混淆，我覺(jué)得一般使用者理解到parser層面便足矣，因?yàn)轭?lèi)型的判別和兼容性檢查在代碼生成階段已經(jīng)不是關(guān)鍵問(wèn)題了，不過(guò)當(dāng)然，只要是良性類(lèi)型提升，無(wú)論哪個(gè)階段都是可以做的，甚至，只要在parse階段編譯器已經(jīng)獲得了正確的類(lèi)型信息，那么，在代碼生成階段對(duì)變量再進(jìn)行非良性的類(lèi)型轉(zhuǎn)換，這也是有保障的設(shè)計(jì)行為。至此，我相信解釋?xiě)?yīng)該完整了...
AspNet技術(shù)：implicitly convert type 'int' to 'short'的原因與解決方法，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
