最新文章專題視頻專題問答1問答10問答100問答1000問答2000關(guān)鍵字專題1關(guān)鍵字專題50關(guān)鍵字專題500關(guān)鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關(guān)鍵字專題關(guān)鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
當(dāng)前位置: 首頁 - 科技 - 知識百科 - 正文

implicitly convert type 'int' to 'short'的原因與解決方法

來源:懂視網(wǎng) 責(zé)編:小采 時間:2020-11-27 22:44:17
文檔

implicitly convert type 'int' to 'short'的原因與解決方法

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 us
推薦度:
導(dǎo)讀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 us

看看下面的代碼:
代碼如下:
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;

你覺得這段代碼能否正確執(zhí)行?結(jié)果會怎樣? 結(jié)果就是:這段代碼會出現(xiàn)編譯錯誤.
正確的代碼應(yīng)該如下:
代碼如下:
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幾種數(shù)據(jù)類型. 像上面的sbyte,byte,short,ushort, clr底層是不支持的,在底層這些類型是用int表示的. CLR的堆棧中壓入的數(shù)字,最小是4字節(jié),小于4字節(jié)的會根據(jù)其類型進行符號擴展或者0擴展為4字節(jié)int型. 這樣四則運算的結(jié)果也是int型,最后再賦值需要進行強制類型轉(zhuǎn)換. 分析一下編譯后的IL代碼就清楚了.

下面這個代碼為什么能編譯呢?
代碼如下:
short sb;
sb=2;
sb += 1;

其實編譯后的IL代碼中最后賦值也包含了類型轉(zhuǎn)換操作.

看下更加詳細的解釋:
代碼如下:
short s=0;
s = s + 1; //報錯,右端是復(fù)雜表達式,1被解釋成int
s+=1; //不報錯,1被解釋成short, 請看下面的解釋
s += 32768; //報錯,顯然32768是不能解釋成short的,只能解釋成int
s+=(s+1); //報錯,右端是復(fù)雜表達式,1被解釋成int

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

       請注意上述解釋主要針對parse階段。實際上,到了代碼生成階段,出于性能等目的,類型可能還會得到進一步提升,如s+=1這個例子,實際上在IL代碼生成階段,這個parse階段識別出來的(short)1最終被提升為了(int)1,這應(yīng)該便是瑞克觀察到的IL參數(shù)4字節(jié)對齊的現(xiàn)象了。其實,為避免混淆,我覺得一般使用者理解到parser層面便足矣,因為類型的判別和兼容性檢查在代碼生成階段已經(jīng)不是關(guān)鍵問題了,不過當(dāng)然,只要是良性類型提升,無論哪個階段都是可以做的,甚至,只要在parse階段編譯器已經(jīng)獲得了正確的類型信息,那么,在代碼生成階段對變量再進行非良性的類型轉(zhuǎn)換,這也是有保障的設(shè)計行為。至此,我相信解釋應(yīng)該完整了...

聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

文檔

implicitly convert type 'int' to 'short'的原因與解決方法

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 us
推薦度:
標(biāo)簽: 解決辦法 解決方法 to
  • 熱門焦點

最新推薦

猜你喜歡

熱門推薦

專題
Top