因?yàn)镃/C++允許程序員做出更多選擇。

選擇更多，那么：

弊端：開發(fā)效率難以提高，因?yàn)橛刑噙x擇需要斟酌。

優(yōu)勢(shì)：執(zhí)行效率可以逼近極限，因?yàn)椴粫?huì)有什么抽象攔住你。

舉個(gè)例子吧：大家可能對(duì)Java無(wú)處不在的“對(duì)象.方法調(diào)用().方法調(diào)用().方法調(diào)用()”記憶猶新，論壇上也到處都是吐槽這個(gè)的。

當(dāng)然，這個(gè)是顯學(xué)，這里并不想討論它。

不過(guò)，還有個(gè)東西藏在表面的繁復(fù)實(shí)現(xiàn)后面，可能很多人并不知道：函數(shù)調(diào)用非常浪費(fèi)時(shí)間，這里面有大把的優(yōu)化空間。

其中，函數(shù)使用的局部變量就是個(gè)很大的問(wèn)題。

對(duì)于c/c++，以及其它任何“傳統(tǒng)”編譯型語(yǔ)言，都可以在函數(shù)內(nèi)定義一個(gè)“局部變量”，這個(gè)局部變量默認(rèn)分配在棧上——而棧是由CPU提供的專門指令硬件維護(hù)的。

因此，棧上數(shù)據(jù)的分配/刪除速度極快（一條指令即可完成）；而且?？臻g是連續(xù)的，所以哪怕在不同函數(shù)間來(lái)回跳轉(zhuǎn)，也不會(huì)出現(xiàn)緩存未命中問(wèn)題；最后，因?yàn)椤昂瘮?shù)抽象”非常完善，所以這里的內(nèi)存分配/回收完全無(wú)需用戶干預(yù)。

當(dāng)然了，這也帶來(lái)了一些問(wèn)題。比如程序員不得不區(qū)分棧上對(duì)象和堆上對(duì)象、遇到異常時(shí)棧上對(duì)象的釋放也變得復(fù)雜而微妙……但總的來(lái)說(shuō)，從這里得到的好處太大，困難與之相比，并不足論。

舉例來(lái)說(shuō)，3D API經(jīng)常需要傳遞point2D或者point3D進(jìn)去。

對(duì)任何“傳統(tǒng)”語(yǔ)言，這都不是個(gè)問(wèn)題：只要把這個(gè)小對(duì)象聲明到棧上，然后調(diào)用相關(guān)API，完成。

甚至，對(duì)大多數(shù)編譯器來(lái)說(shuō)，很容易就能識(shí)別出“這是個(gè)需要傳遞給其它函數(shù)的局部變量”——于是，它會(huì)自動(dòng)把這個(gè)point2D/point3D放進(jìn)寄存器，從而連壓棧/退棧指令都不需要執(zhí)行！

你看，當(dāng)我需要傳遞一個(gè)小對(duì)象時(shí)，用c/c++，壓根無(wú)需思考，聲明成局部變量，編譯器就把該做的事情全幫我做了——傳遞它，除了會(huì)占用幾個(gè)通用寄存器，我甚至無(wú)需付出哪怕一條指令的代價(jià)！

哪怕最差情況，傳參的代價(jià)也不過(guò)是執(zhí)行了幾次push/pop這兩條機(jī)器指令而已。

剛好我這里有資料需要的可以私我