短文漲姿勢，看了不白看，不關(guān)注等啥？

我們知道，在Java以及很多高級編程語言當(dāng)中，都有一種運(yùn)算符叫做復(fù)合賦值運(yùn)算符。復(fù)合賦值運(yùn)算符由兩個符號組成，它所能完成的運(yùn)算操作也分為兩步：第一步是運(yùn)算，第二步是賦值。比如說：

上面的這兩條語句相當(dāng)于

但是，如果碰到下面這樣的情況，a的值該應(yīng)該是多少呢？

有人認(rèn)為應(yīng)該按以下方式來計(jì)算，因?yàn)槲覀兌贾?#xff0c;在四則運(yùn)算規(guī)則中，遵循“先乘除，后加減”的原則

按照這樣的方式來計(jì)算，得到a的值應(yīng)該是7，但實(shí)際運(yùn)行程序所得到的結(jié)果是8。這是為什么呢？

就是因?yàn)閺?fù)合賦值運(yùn)算符在完成運(yùn)算的時候，遵循一個規(guī)則：把“=”右邊當(dāng)作整體！也就是說，剛才的運(yùn)算和賦值操作應(yīng)該被解釋為以下形式

因此，按照這種方式，“=”右邊的“3+1”應(yīng)該被當(dāng)作整體，優(yōu)先進(jìn)行運(yùn)算，所以得到的最終計(jì)算結(jié)果就是變量a的值為8。

我們再來看另外一個問題，這一次，我們把變量a的類型由原來的int改為short。

我們這么寫代碼沒有任何問題，能夠順利通過編譯。但是，如果我們沒有使用復(fù)合賦值運(yùn)算符，而是按如下所示的方式編寫代碼

在這種情況下，大家可以看到代碼不能通過編譯。我們把一個算術(shù)表達(dá)式的運(yùn)算結(jié)果賦值給byte或者是short類型的變量，有時候會引起編譯錯誤，所以按這種方式寫代碼會導(dǎo)致編譯錯誤。關(guān)于引起這種錯誤的原因，大家可以看我的另一篇文章《Java語言中為byte和short類型變量賦值為啥會報(bào)錯？看完秒懂》，該文對此現(xiàn)象有詳細(xì)解釋。我們現(xiàn)在重點(diǎn)討論使用復(fù)合賦值運(yùn)算符進(jìn)行操作的時候，同樣會有給short類型變量賦值的操作，為什么就不報(bào)錯呢？原因就是：使用復(fù)合賦值運(yùn)算符在對變量進(jìn)行賦值的時候，編譯器會“暗地里”加上一個強(qiáng)制類型轉(zhuǎn)換的操作。也就是說，使用復(fù)合賦值運(yùn)算符進(jìn)行操作的時候，實(shí)際上等同于如下寫法

這種強(qiáng)制類型轉(zhuǎn)換，其實(shí)有可能讓我們的程序在不經(jīng)意間產(chǎn)生莫名其妙的錯誤，請看下面的例子

這一次，我們把a(bǔ)的初始值由原來的2改成了20000，并且在代碼中還加入了輸出a的語句，那么，輸出結(jié)果會是多少呢？首先來講，這段代碼并沒有報(bào)錯，那么這個輸出結(jié)果會讓人很多人大吃一驚，它并不是我們想象的80000，而是竟然輸出了14464！

之所以會輸出這樣的結(jié)果，就是因?yàn)?0000已經(jīng)超出了short類型數(shù)據(jù)的最大值，而我們強(qiáng)制把這個已經(jīng)超過最大值的“80000”經(jīng)過強(qiáng)制類型轉(zhuǎn)換賦值給short變量，就會產(chǎn)生“溢出”，最終導(dǎo)致實(shí)際賦給變量a的是一個錯誤的值！最可惡的是，因?yàn)槭菑?qiáng)制類型轉(zhuǎn)換之后進(jìn)行的賦值，所以編譯器并不報(bào)錯，從而導(dǎo)致很多人掉到坑里還不知道！

通過這個篇文章，大家可以看到：一個簡單的復(fù)合賦值運(yùn)算符竟然也“暗藏殺機(jī)”，我們平時編程一定要小心哦！

看短文，漲姿勢，如想系統(tǒng)學(xué)習(xí)Java編程，點(diǎn)擊下方的“了解更多”即可，不讓你進(jìn)去，用QQ登錄就可以啦！有問題也可以加入我的QQ群一起討論！

總結(jié)

以上是生活随笔為你收集整理的int** 赋值_关于Java语言复合赋值运算符的两个问题，快来瞧瞧的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。