为什么C++（感谢waterwalk翻译）
為什么C++（感謝waterwalk翻譯）
?
劉未鵬(pongba) /文
waterwalk?/譯
C++的羅浮宮(http://blog.csdn.net/pongba)
?
首先非常感謝waterwalk的辛勤翻譯:-) waterwalk把翻譯回貼在原文的下面了，為了方便閱讀我提取出來編輯以后重發(fā)一個帖子。這篇文章原本是想對最近C/C++爭論系統(tǒng)的整理一下一些思考的，但由于一開始的時候用英文寫了兩段，后來就干脆都用英文了，造成很多人閱讀的麻煩，在此抱歉。不過好在waterwalk翻譯了整篇文章，于是單獨(dú)貼在這里:-)
?
另，原文在這里。
?
問題
為什么用C++呢??在你皺著眉頭離開之前，試著回答這個簡單的問題。效率，是么？人人都知道這個。但情況是，當(dāng)一個人開始討論編程語言或與其相關(guān)的話題時，他必須要非常明確而有針對性。為什么呢？我來問你另一個問題：如果效率是人們使用C++的唯一理由，那么為啥不直接用C呢？C被認(rèn)為比C++效率更高（嗯嗯，我知道C沒有比C++的效率高多少，所以這里別誤解我的意思，因?yàn)榧词顾鼈兌咝氏嗤?#xff0c;剛才的問題依然存在）。
?
迷思
我知道你又要說“更好的抽象機(jī)制”了，因?yàn)楫吘笴++是要設(shè)計(jì)成一個更好的C的。C++沒有犧牲效率，同時又添加了這么多高級特性。但問題是，“開發(fā)者們真的需要這些高級特性么？”。畢竟我們一直聽人講KISS之類的東西。我們也都聽到有聲稱C比C++更KISS所以我們要用C云云。這種持續(xù)不斷的爭論將C與C++之間的比較變成了一個大大的迷題（或者說是混亂）。令人驚訝的是，貌似的確有很多人更加傾向于用C，最大的理由就是C++實(shí)在是太難用對了。甚至Linus也這么想。
?
這種現(xiàn)象最大的影響就是當(dāng)人們在C和C++之間權(quán)衡時，使人們傾向于使用C。而且一旦人們開始用C，他們很快就適應(yīng)并滿足了（其實(shí)，在任何語言乃至任何人類活動中都有此現(xiàn)象，C++亦然，比如常常聽到有人說“XX語言我用了這么多年，一直用得好好的”，照這種說法任何圖靈完備的語言還不都是能用來編程？）。于是即使他們還沒有試試C++，或者他們還沒成為好的C++程序員時，他們就開始聲稱C比C++更好了。然而其實(shí)呢，真實(shí)的答案往往總是取決于實(shí)際情況的。
?
我說過“取決于實(shí)際情況”了么？那到底實(shí)際情況是什么呢？顯然，有些領(lǐng)域C是更好的選擇。例如設(shè)備驅(qū)動開發(fā)就不需要那些OOP/GP技巧。而只是簡單的處理數(shù)據(jù)，真正重要的是程序員確切地知道系統(tǒng)是如何運(yùn)轉(zhuǎn)的，以及他們正在做什么。那么寫操作系統(tǒng)呢？我本人并沒有參與任何操作系統(tǒng)的開發(fā)，但我讀過不少操作系統(tǒng)代碼（大多是unix的）。我的感覺是操作系統(tǒng)很大一部分也不需要OOP/GP。
?
但是，這就表示在所有效率重要的領(lǐng)域，C都是比C++更好的選擇么？未必。
?
答案
讓我們一個一個來分析。
?
首先，當(dāng)人們關(guān)注效率時，有2種效率——時間效率（例如OS，運(yùn)行時庫，實(shí)時應(yīng)用程序，high-demanding的系統(tǒng)）和空間效率（例如各種嵌入式系統(tǒng)）。但是，這樣的分類并不能幫我們決定用C還是C++，因?yàn)镃和C++的時空效率都很高。真正影響選擇語言的因素是業(yè)務(wù)邏輯（這里的“業(yè)務(wù)邏輯”并非表示“企業(yè)應(yīng)用業(yè)務(wù)”）。例如，使用OOP/GP來表達(dá)邏輯（或者說代碼的結(jié)構(gòu)）好呢，還是就只用數(shù)據(jù)和過程好呢？
?
據(jù)此觀點(diǎn)，我們可以把應(yīng)用程序大致分為兩類（當(dāng)然前提是關(guān)注的是C/C++而不是java/C#/ruby/erlang等等）：底層應(yīng)用程序和高層應(yīng)用程序。這里底層是指像OB/OO和GP沒啥用處的地方，?其余歸到高層。顯然，在所有C/C++應(yīng)用的領(lǐng)域（這些領(lǐng)域需要C/C++的效率），屬于高層的應(yīng)用有很多（可以看看Bjarne Stroustrup在他主頁上的列表）。在這些領(lǐng)域中，抽象至少是和效率一樣重要的。而這些正是C++適用的場合。
?
等等還有。即使在程序員不需要高級抽象的領(lǐng)域，也不是就絕對用不到C++的。為啥呢？僅僅是因?yàn)槟愕拇a中沒有用類或模板并不意味著不能用以類或模板實(shí)現(xiàn)的庫。因?yàn)橛腥绱吮姸喾奖愕腃++庫（還有即將到來的tr1/tr2），我覺得有充分的理由在這些領(lǐng)域中使用C++——你可以在編碼時僅使用C++中的C核心（以任何你喜歡的方式來KISS），同時還能用強(qiáng)大的C++庫（比如STL容器、算法和tr1/tr2的組件）。
?
最后，我認(rèn)為人們還常常忽略了一點(diǎn)——有時KISS也是建立在抽象上的。我覺得Matthew Wilson在他新書《Extended STL，卷1》的序言中對此做了很好的闡釋。他寫了2段代碼，一段用C，另一段用C++:
?
// in C
DIR*??dir = opendir(".");
if(NULL != dir)
{
??struct dirent*??de;
??for(; NULL != (de = readdir(dir)); )
??{
????struct stat st;
????if( 0 == stat(de->d_name, &st) &&
????????S_IFREG == (st.st_mode & S_IFMT))
????{
??????remove(de->d_name);
????}
??}
??closedir(dir);
}
?
// in C++
readdir_sequence entries(".", readdir_sequence::files);
?
std::for_each(entries.begin(), entries.end(), ::remove);
?
而在C++09里面更簡單：
?
// in C++09
std::for_each(readdir_sequence(".", readdir_sequence::files), ::remove);
?
也就是說，我認(rèn)為即使一個人在自己的代碼里不需要類或模版，他也有理由用C++，因?yàn)樗玫哪切┓奖愕腃++庫用到了類和模板。如果一個高效的容器（或智能指針）能把你從無聊的手動內(nèi)存管理中解放出來，為啥還要用那原始的malloc/free呢？如果一個更好的string類（我可沒說std::string，地球人都知道那個不是C++中能做出的最好的string類）或正則表達(dá)式類能把你從一坨一坨的、你看都不想看的處理字符串的代碼中解脫出來，那么為啥還要手動去做這些事呢？如果一個?"transform"（或"for_each"）能夠用一行代碼把事情漂亮搞定，為啥還要手寫一個for循環(huán)呢？如果高階函數(shù)能滿足你的需要，那么為啥還要用笨拙的替代方法呢？（OK，我知道，最后兩個需要C++加入lambda支持才真正擺脫雞肋的罵名——這正是C++0x的任務(wù)嘛）
?
總之，我認(rèn)為KISS并不等同于“原始”；KISS意味著用最適合的工具來做事情，這里“最合適”的意思是工具能夠幫你以盡量直接簡潔的方式來表達(dá)思想，同時又不降低代碼的可讀性，另外還保持代碼容易理解。
?
真正的問題
人們可能會說，相較于被正確使用而言，C++（遠(yuǎn)遠(yuǎn)）更容易被錯誤使用。而相比而言，C程序的復(fù)雜性更容易管理和控制。在C++中，一個普通程序員很可能會寫出一堆高度耦合的類，很快情況就變得一團(tuán)糟。但這個其實(shí)是另外一個問題。在另一方面，這種事情也很可能發(fā)生在任何一門面向?qū)ο笳Z言中，因?yàn)榭偸怯谐绦騿T在還沒弄懂什么是HAS-A和IS-A之前，就敢于在類上再寫類，疊床架屋的一層一層摞上去。他們學(xué)會了在一門特定的語言中如何定義類，如何繼承類的語法，然后他們就認(rèn)為自己已經(jīng)掌握了OOP的精髓了。另一方面，這一問題在C++中更為嚴(yán)重，因?yàn)镃++有如此眾多的偶然復(fù)雜性在阻礙設(shè)計(jì)；而且C++又是如此靈活，很多問題在C++中都有好幾種解決辦法（想想那么多的GUI庫吧），于是在這些選擇中進(jìn)行權(quán)衡本身就成了一個困難。C++中的非本質(zhì)復(fù)雜性是其歷史包袱使然，而C++0x正是要努力消除這些非本質(zhì)復(fù)雜性（在這方面C++0x的工作的確做得很不錯）。對于設(shè)計(jì)來說，靈活性不是個壞事情——可以幫助好的設(shè)計(jì)者作出好的設(shè)計(jì)。如果有人抱怨說這個太費(fèi)腦細(xì)胞了，那可能是這個設(shè)計(jì)者本身的問題，而不能怪語言。可能就不該讓他來作設(shè)計(jì)。如果你擔(dān)心C++的高級特性會把你的同事引入歧途，把項(xiàng)目搞砸，那你也許應(yīng)該制定一份編碼標(biāo)準(zhǔn)并嚴(yán)格推行（或者你也可以遵循C++社群這些年積攢下來的智慧，或者在必要時，只使用C++中的C或C with class那部分），而不是因?yàn)橛酗L(fēng)險就躲開C++（其實(shí)這些風(fēng)險可以通過一些政策來避免的），因?yàn)槟菢拥脑?#xff0c;你就沒法用那些C++的庫了。
?
另一方面，其實(shí)一個更為重要的問題是一個心理學(xué)問題——如果一門語言中存在某個奇異的特性或旮旯，那么遲早總會有人發(fā)現(xiàn)的，總會有人為之吸引的，然后就使人們從真正有用的事情中分心出來（這有點(diǎn)像Murphy法則），更不用說那些有可能對真正問題帶來（在某種程度上）漂亮的解決方案的語言旮旯了。人們本性上就容易受到稀有資源的誘惑。奇技淫巧是稀有資源，于是奇技淫巧便容易吸引人們的注意力，更別說掌握一個技巧還能夠讓那人在他那圈子里感覺非常牛了。退一萬步，你會發(fā)現(xiàn)，即使是一個廢柴技巧也能引起人們足夠的興趣來。
?
C++中有多少陰暗角落呢？C++中又有多少技巧呢？總的來說，C++中，有多少非本質(zhì)復(fù)雜性呢？（懂一定C++的人一定知道我在說什么）
?
平心而論，近年來（現(xiàn)代C++中）發(fā)現(xiàn)的大多數(shù)技巧或（如果你愿意稱之為）技術(shù)實(shí)際上都是由實(shí)際需求驅(qū)動的，尤其是需要實(shí)現(xiàn)高度靈活而又普遍適用（generic）的類庫?（例如boost中的那些玩意）。而這些技巧也的確（在某種程度上）提供了對實(shí)際問題的漂亮解決方案。讓我們來這么想一下，如果你處于一個兩難境地：要么用那些奇技淫巧來做點(diǎn)很有用的東西，要么不做這樣其他人也就沒得用。你會如何選擇呢？我知道boost的英雄們選擇了前者——不管多么困難多么變態(tài)多么齷齪，把它做出來！
?
但所有這些爭論都不能改變一個事實(shí)：我們理應(yīng)享有一個語言，能夠讓我們用代碼清晰的表達(dá)思想。以boost.function/boost.bind/boost.tuple為例，variadic templates可以大大簡化這幾個庫的實(shí)現(xiàn)（減至幾乎是原先1/10的代碼行數(shù)），同時代碼也（遠(yuǎn)遠(yuǎn)）更加簡潔易懂。Auto，initializer-list，rvalue-reference，template-aliasing，strong-typed enums，delegating-constructors，constexpr，alignments，inheriting-constructors，等等等等，所有這些C++0x的特性，都有一個共同目的——消除語言中多方面的非本質(zhì)復(fù)雜性或語言中的尷尬之處。
?
正如Bjarne Stroustrup所說，很顯然C++太過復(fù)雜了，很顯然人們被嚇壞了，并且時不時就不用C++了。但“人們需要相對復(fù)雜的語言去解決絕對復(fù)雜的問?題”。我們不能通過減少語言特性而使其更加強(qiáng)大。復(fù)雜的特性就連模板甚至多繼承這樣的也是有用的——如果你正好需要它們，而且如果你極其小心使用，不要搬起石頭砸自己的腳的話。其實(shí)在所有C++的復(fù)雜性當(dāng)中，真正阻礙了我們的是“非本質(zhì)復(fù)雜性”（有人稱之為“尷尬之處”），而不是語言所支持的編程范式（其實(shí)也就3個而已）。而這也正是我們應(yīng)該擁抱C++0x的重要原因，因?yàn)镃++0x正是要消除那些長期存在的非本質(zhì)復(fù)雜性，同時也使得那些奇技淫巧不再必要（很顯然，目前這些技巧堆積如山，翻翻那些個C++的書籍，或者瞅瞅boost庫，你就知道我在說啥了），這樣我們就能夠直觀清晰的表達(dá)思想。
?
結(jié)論
C++難用，更難用對。所以當(dāng)你決定用它時，要小心，要時刻牢記自己的需求，所要達(dá)到的目的。這里有一個簡單的指南：
?
我們需要高效率么？
?
如果需要，那么
?
我們需要抽象么（請仔細(xì)思考這一點(diǎn)，因?yàn)楹茈y評估使用C++高級特性是否能夠抵消誤用這些機(jī)制的風(fēng)險；正確的回答取決于程序員的水平有多高，遵循哪種編碼標(biāo)準(zhǔn)以及編碼標(biāo)準(zhǔn)執(zhí)行得如何，等等）？
?
如果是，那么用C++吧。如果不是，那么，
?
我們需要用C++庫來簡化開發(fā)么？
?
如果是，那就用C++吧。但同時必須時刻牢記你在做什么——如果你的代碼不需要那些“漂亮的”抽象，那就別試圖使用以免陷入其中。別只是因?yàn)槟阍?cpp文件中寫代碼以及你用的是C++編譯器就要用類啊、模板啊這些東西。
?
如果不是，那就用C，不過你又會想為啥不僅僅使用C++中屬于C的那部分核心呢？還是老原因：人們很容易就陷入到語言的“漂亮”特性中去了，即使他們還不知道這些特性是否有用。我都記不清有多少次自己寫了一大堆的類和繼承，到最后反倒要問自己“要這么些個類和繼承做什么呀？”。所以，如果你能堅(jiān)持只用C++中C或C with class的那部分，并遵循“讓簡單的事情保持簡單”的理念；或者你需要把C代碼遷移到C++中來的話，那么就用C++吧，但要十分小心。另一方面，如果你既不需要抽象機(jī)制，也不需要C++庫，因?yàn)槭虑榉浅：唵?/strong>，不需要方便的組件例如容器和字符串，或者你已認(rèn)定C++能夠給項(xiàng)目帶來的好處微乎其微，不值得為之冒風(fēng)險，或者干脆就沒那么多人能用好C++，那么可能你還是只用C的好。
?
底線是：讓簡單的事情保持簡單（但同時也請記住：簡單性可以通過使用高級庫來獲得）；必要時才使用抽象（切記不可濫用；遵循好的設(shè)計(jì)方法和最佳實(shí)踐）。
?
--
歡迎參加劉未鵬(pongba)的討論組，討論編程相關(guān)的任何問題:)
TopLanguage
總結(jié)
以上是生活随笔為你收集整理的为什么C++（感谢waterwalk翻译）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Why C++
- 下一篇： 偷梁换柱——揭开多态的面纱