|
作者：RedHatter 同僚們閑聊，突然就聊到了a+++++a的問題。這種純屬C語言 “二” 級的問題應(yīng)該是從a+++a引申出來的吧。于是乎兄弟姐妹們開始討論它的運(yùn)算結(jié)果，以及改如何理解。更有人寫出(a++)+(++a) a+(++(++a)) ((a++)++)+a這樣的東西，問應(yīng)該如何計(jì)算。我表示鴨梨很大... 針對這樣的問題我的觀點(diǎn)是，“絕不小心求證，只管大膽胡說!” 哈哈，當(dāng)然了，我還是要對我的師兄弟們負(fù)責(zé)的，所以我下面的“胡說”中會盡量有理有據(jù)。 看法一： a=a+++++a這個東西可以用來討論，甚至是討論它的無所事處，作為增長知識和發(fā)現(xiàn)自身理解問題的漏洞是可以的。但是絕對不能拿來作為考試題目，特別是選擇題或填空題等客觀題目。但是如果作為一道主觀探討題還是挺有趣的，理解深刻的人一定可以寫的很好。 看法二： a=a+++++a的編譯和執(zhí)行結(jié)果是隨機(jī)的，可能有些屌絲編譯器自認(rèn)為自己很牛，可以處理這樣的語句，并把它編譯出來而不報任何警告。那么我首先建議這樣的編譯器別用了，其次我要說這個東西的編譯結(jié)果并不重要，重要的是千萬不要在項(xiàng)目代碼中這樣寫。 下面讓我們來看一下試驗(yàn)： 試驗(yàn)環(huán)境: 發(fā)行版： [zorro@dhcp-65-110 tmp]$ cat /etc/issue Fedora release 19 (Schrödinger’s Cat) Kernel \r on an \m (\l) 內(nèi)核和體系結(jié)構(gòu)： [zorro@dhcp-65-110 tmp]$ uname -a Linux dhcp-65-110.nay.redhat.com 3.11.9-200.fc19.x86_64 #1 SMP Wed Nov 20 21:22:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux 編譯器： [zorro@dhcp-65-110 tmp]$ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131017/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131017/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) (GCC) 為什么要列這么詳細(xì)?因?yàn)槲蚁敫嬖V你，細(xì)微的一個編譯gcc時使用的編譯選項(xiàng)的差別都有可能導(dǎo)致使用gcc時編譯結(jié)果的不一樣。 在Linux系統(tǒng)中，每個軟件基本都是通過三個基本步驟從源代碼到安裝進(jìn)系統(tǒng)運(yùn)行的。這三個步驟是： configure make make install 比如configure時的不同選項(xiàng)和參數(shù)會決定代碼編譯出來的軟件的不同特征。好了，這里不多說這個，言歸正傳。寫一個簡單的程序用來測試： #include int main(){ int a = 1; a = a+++++a; printf("a=%d\n", a); return 0; } 我們來在上面說的環(huán)境下用gcc編譯看看： [zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall testcode.c: 在函數(shù)‘main’中: testcode.c:5:9: 錯誤：自增操作數(shù)必須是左值 a = a+++++a; ^ 好吧，倒霉的中文翻譯讓人看不懂，我們改成英文重新來一下： 本文引用地址：http://www.eepw.com.cn/article/198269.htm [zorro@dhcp-65-110 tmp]$ LANG=C [zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall testcode.c: In function 'main': testcode.c:5:9: error: lvalue required as increment operand a = a+++++a; ^ 好了，這回看懂了，意思是說++這個自增操作需要一個左值。這么說的話編譯器可能是這樣理解的： a=((a++)++)+a;或者a=a+(++(++a)); 讓我們分別改成這兩種情況嘗試一下： 編譯a = ((a++)++)+a的結(jié)果是： [zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall testcode.c: In function 'main': testcode.c:5:12: error: lvalue required as increment operand a = ((a++)++)+a; ^ 編譯a = a+(++(++a))的結(jié)果是： [zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall testcode.c: In function 'main': testcode.c:5:9: error: lvalue required as increment operand a = a+(++(++a)); ^ 和寫成a = a+++++a的編譯錯誤差不多。這就是說我的gcc認(rèn)為++操作是不能以++a或者a++作為操作數(shù)的。 再看一下這樣寫： a=a++ + ++a 請嚴(yán)重注意在中間那個+兩邊各有一個空格，讓我們編譯一下： [zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall testcode.c: In function 'main': testcode.c:5:4: warning: operation on 'a' may be undefined [-Wsequence-point] a = a++ + ++a; testcode.c:5:4: warning: operation on 'a' may be undefined [-Wsequence-point] 這次沒有error發(fā)生，只有兩個警告。這樣應(yīng)該編譯出可執(zhí)行文件mytest了。先不管這兩個警告我們執(zhí)行一下看看： [zorro@dhcp-65-110 tmp]$ ./mytest a=4 嗯，看來a=1;a=a++ + ++a是這樣做的： a++的結(jié)果是1。然后++a時a初始是2，++后變成3。結(jié)果就是a=1 + 3也就是4。 雖然是編譯出來了，并且也執(zhí)行了，但是這樣好嗎?對，當(dāng)然是不好。光那兩個警告擺在那就夠讓人提心吊膽了。那個警告的意思是在說a上的操作可能是沒有明確定義的，好像聽著很晦澀難懂。好吧，我翻譯成21世紀(jì)現(xiàn)代漢語告訴，它的意思的：我勸你別這么干，你要是非要這么干，到執(zhí)行時別怪我跟你玩虛的。 有人說我用括號讓意思明確一些應(yīng)該行了吧?編譯一下看看： [zorro@dhcp-65-110 tmp]$ gcc -o mytest testcode.c -Wall testcode.c: In function 'main': testcode.c:5:4: warning: operation on 'a' may be undefined [-Wsequence-point] a = (a++) + (++a); testcode.c:5:4: warning: operation on 'a' may be undefined [-Wsequence-point] 唉，看來還是不行。為什么呢?我個人的理解是編譯器可能想告訴你加法運(yùn)算符的左右兩邊如果都是算式，那么不一定哪邊先被執(zhí)行。也就是加法運(yùn)算符的左右兩個操作數(shù)不一定誰先被讀取執(zhí)行，那么當(dāng)左右兩個運(yùn)算又相互耦合時，聰明的編譯器就會告訴你千萬別這么干。你這么干了在我這可能是一種結(jié)果，在別的地方可能就是另一種結(jié)果了，但是不能完全指望編譯器幫你檢查出來，上面如果我們把-Wall選項(xiàng)去掉再編譯，那么就不會有這個警告了，或者有的編譯器目光狹窄根本不認(rèn)為這是個問題，那么問題就非常嚴(yán)重了。如果是一個幾萬行幾十萬行甚至更多行的項(xiàng)目，這樣的問題是很難調(diào)式發(fā)現(xiàn)的。所以千萬要注意! 我們來總結(jié)一下，上面說了兩個重要的問題： 1、++運(yùn)算符不能以++a或a++作為運(yùn)算數(shù)，至少在gcc上不讓這樣，所以建議你別這樣寫。 2、一些多目運(yùn)算符號(如加減乘除與或等)，多個運(yùn)算數(shù)如果是表達(dá)式，特別是耦合關(guān)系很強(qiáng)的表達(dá)式，千萬要分開順序重新組織代碼，否則你不知道它先讓哪個執(zhí)行。 對于第二點(diǎn)可以擴(kuò)展到函數(shù)等地方，例如printf()函數(shù)，很多人喜歡在printf里寫表達(dá)式，如: printf("%d,%d,%d", 表達(dá)式1，表達(dá)式2，表達(dá)式3); 當(dāng)這3個表達(dá)式的執(zhí)行順序很重要時，你千萬不要自認(rèn)為它一定是按照1,2,3的順序運(yùn)行，它有可能是3,2,1的順序的。 類似的地方還有很多，要時刻注意代碼安全的重要性。 |
