從最簡(jiǎn)單的運(yùn)算符加號(hào)(+)說起，加號(hào)(+)是個(gè)二元運(yùn)算符——也就是說，加號(hào)只把兩個(gè)數(shù)聯(lián)接起來，從來不把第三個(gè)或者更多的聯(lián)接起來。
因此，“1加2加3” 在計(jì)算機(jī)中被表述為：
(1 + 2) + 3 // a或者
1 + (2 + 3) // b雖然我們通常寫做 1 + 2 + 3，但是并不意味這它和我們數(shù)學(xué)中的 1+2+3 是等價(jià)的。
那么數(shù)學(xué)中的 1+2+3 到底表示的是 a 呢，還是 b 呢？
如果計(jì)算機(jī)的求值是左結(jié)合的，那么此表達(dá)式等價(jià)于第一種a； 如果是右結(jié)合的，那么此表達(dá)式等價(jià)于第二種b。
1 + 2 + 3 簡(jiǎn)單的理解就是 “把1、2、3加在一起”， 確實(shí)，在我們接觸到的數(shù)學(xué)里面，就是把三個(gè)數(shù)加起來。 但是在編程語言中，卻不僅僅這樣。
就像前面說的那樣，+號(hào)無法操作三個(gè)或者更多的數(shù)，參與加法運(yùn)算的只能是兩個(gè)數(shù)。
順便說一句，正號(hào)、負(fù)號(hào)是一元運(yùn)算符，雖然它們和二元運(yùn)算符加、減用相同的符號(hào)， 但是他們卻是不同的，所以不要想當(dāng)然的認(rèn)為 +4 就等價(jià)于 0+4，其實(shí)它們不是等價(jià)的，
+4 是一個(gè)整數(shù)，但是 0+4 是一個(gè)加法表達(dá)式，這個(gè)表達(dá)式的求值結(jié)果正好是 +4。
在 java 中，我們可以寫 short a = +4，但是當(dāng)我們寫 short a = 0 + 4 時(shí)則產(chǎn)生一個(gè)警告。
還有一個(gè)其它例子，同樣是關(guān)于 short 的，
short b = 1;
short b = b + 4; // 警告
short b += 4; // 無警告那么 1 + 2 + 3 是如何運(yùn)算的呢？ 在馮諾依曼體系架構(gòu)的編程語言中， 這里有一個(gè)副作用——我習(xí)慣稱那些“計(jì)算機(jī)的運(yùn)算過程與程序員的大腦思考過程不一樣時(shí)，則稱為副作用”（雖然書本里面沒有這么寫過，但我一向這么認(rèn)為）， 本來你以為會(huì)是這樣，結(jié)果計(jì)算機(jī)偏偏就不是這樣做的，我稱他為副作用。
如果看過前面的『語句與表達(dá)式』，這可以這么理解：
1 + 2 是一個(gè)表達(dá)式，它的返回值是 3。 這個(gè)表達(dá)式的返回值再參加到另一個(gè)表達(dá)式中 3 + 3，最后得出結(jié)果6。
我們用語句（Statement）來改寫這段代碼：
// 計(jì)算 1 + 2 + 3
var a = 1 + 2;
var b = a + 3;如果我們用 lisp 語言對(duì)這個(gè)表達(dá)式求值，則沒有副作用。
(+ (+ 1 2) 3)如果你還沒有懂，或者這個(gè)例子太有特殊性，那么我們換一個(gè)
5 > 4 > 3在數(shù)學(xué)中，這個(gè)算式的值為 true。當(dāng)我們用C語言來寫這段代碼，它返回的確實(shí) false。
原因和上面的一樣，大于號(hào)(>)是二元運(yùn)算，它無法直接比較三個(gè)數(shù)，5 > 4 返回的結(jié)果是 true， 當(dāng)用 true 和 3 比較時(shí)，true 被轉(zhuǎn)換稱 1，也就是 1 > 3，最終的結(jié)果自然就是 false 了。
總之，回歸到了『語句與表達(dá)式』篇的那個(gè)觀點(diǎn)：在編程語言中 每個(gè)表達(dá)式都有一個(gè)值。
編程語言中的運(yùn)算符和數(shù)學(xué)中的運(yùn)算器雖然一樣，但是它們卻并不等同。 當(dāng)你寫程序時(shí)，要寫給人看； 當(dāng)你調(diào)試程序時(shí)，要學(xué)會(huì)用計(jì)算機(jī)的方式思考代碼的含義。
我習(xí)慣于把運(yùn)算符理解為函數(shù)，比如 2 + 5 其實(shí)就是 add(2, 5) 或者 2.add(5)。 難道我會(huì)偷偷的告訴你 “其實(shí)很多語言都是這么做的”。

最新評(píng)論