JavaScript是世界上最受誤解的語言，其實C++何嘗不是。坊間流傳的錯誤的C++學(xué)習(xí)方法一抓就是一大把。我自己在學(xué)習(xí)C++的過程中也走了許多彎路，浪費了不少時間。
為什么會存在這么多錯誤認識?原因主要有三個，一是C++語言的細節(jié)太多。二是一些著名的C++書籍總在(不管有意還是無意)暗示語言細節(jié)的重要性和有趣。三是現(xiàn)代C++庫的開發(fā)哲學(xué)必須用到一些犄角旮旯的語言細節(jié)(但注意，是庫設(shè)計，不是日常編程)。這些共同塑造了C++社群的整體心態(tài)和哲學(xué)。
單是第一條還未必能夠成氣候，其它語言的細節(jié)也不少(盡管比起C++起來還是小巫見大巫)，就拿javascript來說，作用域規(guī)則，名字查找，closure，for/in，這些都是細節(jié)，而且其中還有違反直覺的。但許多動態(tài)語言的程序員的理念我猜大約是學(xué)到哪用到哪罷。但C++就不一樣了，學(xué)C++之人有一種類似于被暗示的潛在心態(tài)，就是一定要先把語言核心基本上吃透了才能下手寫出漂亮的程序。這首先就錯了。這個意識形成的原因在第二點，C++書籍。市面上的C++書籍不計其數(shù)，但有一個共同的缺點，就是講語言細節(jié)的書太多——《C++ gotchas》，《Effective C++》，《More Effective C++》，但無可厚非的是，C++是這樣一門語言：要拿它滿足現(xiàn)代編程理念的需求，尤其是C++庫開發(fā)的需求，還必須得關(guān)注語言細節(jié)，乃至于在C++中利用語言細節(jié)已經(jīng)成了一門學(xué)問。比如C++模板在設(shè)計之初根本沒有想到模板元編程這回事，更沒想到C++模板系統(tǒng)是圖靈完備的，這也就導(dǎo)致了《Modern C++ Design》和《C++ Template Metaprogramming》的驚世駭俗。
這些技術(shù)的出現(xiàn)為什么驚世駭俗，打個比方，就好比是一塊大家都認為已經(jīng)熟悉無比，再無秘密可言的土地上，突然某天有人挖到原來地下還蘊藏著最豐富的石油。在這之前的C++雖然也有一些細節(jié)，但也還算容易掌握，那可是C++程序員們的happy old times，因為C++的一切都一覽無余，everything is figured out。然而《Modern C++ Design》的出世告訴人們，“瞧，還有多少細節(jié)你們沒有掌握啊。”于是C++程序員們久違的激情被重燃起來，奮不顧身的踏入細節(jié)的沼澤中。尤其是，模板編程將C++的細節(jié)進一步挖掘到了極致——我們干嘛關(guān)心涉及類對象的隱式轉(zhuǎn)換的優(yōu)先級高低?看看boost::is_base_of就可以知道有多詭異了。
但最大的問題還在于，對于這些細節(jié)的關(guān)注還真有它合適的理由：我們要開發(fā)現(xiàn)代模板庫，要開發(fā)active library，就必須動用模板編程技術(shù)，要動用模板編程技術(shù)，就必須利用語言的犄角旮旯，enable_if，type_traits，甚至連早就古井無波的C宏也在亂世中重生，看看boost::preprocessor有多詭異就知道了，連C宏的圖靈完備性(預(yù)編譯期的)都被挖掘出來了。為什么要做這些?好玩?標榜?都不是，開發(fā)庫的實際需求。但這也正是最大的悲哀了。在boost里面因?qū)嶋H需求而動用語言細節(jié)最終居然能神奇的完成任務(wù)的最好教材就是boost::foreach，這個小設(shè)施對語言細節(jié)的發(fā)掘達到了驚天地泣鬼神的地步，不信你先試著自己去看看它的源代碼，再看看作者介紹它的文章吧。而boost::typeof也不甘其后——C++語言里面有太多被“發(fā)現(xiàn)”而不是被“發(fā)明”的技術(shù)。難道最初無意設(shè)置這些語言規(guī)則的家伙們都是Oracles?
因為沒有variadic templates，人們用宏加上缺省模板參數(shù)來實現(xiàn)類似效果。因為沒有concepts，人們用模板加上析構(gòu)函數(shù)的細節(jié)來完成類似工作。因為沒有typeof，人們用模板元編程和宏加上無盡的細節(jié)來實現(xiàn)目標… C++開發(fā)者們的DIY精神不可謂不強。
然而，如果僅僅是因為要開發(fā)優(yōu)秀的庫，那么涉及這些細節(jié)都還是情有可原的，至少在C++09出現(xiàn)并且編譯器廠商跟上之前，這些都還能說是不得已而為之。但我們廣大的C++程序員呢?大眾是容易被誤導(dǎo)的，我也曾經(jīng)是。以為掌握了更多的語言細節(jié)就更牛，但實際卻是那些語言細節(jié)十有八九是平時編程用都用不到的。C++中眾多的細節(jié)雖然在庫設(shè)計者手里面有其用武之地，但普通程序員則根本無需過多關(guān)注，尤其是沒有實際動機的關(guān)注。一般性的編碼實踐準則，以及基本的編程能力和基本功，乃至基本的程序設(shè)計理論以及算法設(shè)計。才是真正需要花時間掌握的東西。
學(xué)習(xí)最佳編碼實踐比學(xué)習(xí)C++更重要。看優(yōu)秀的代碼也比埋頭用差勁的編碼方式寫垃圾代碼要有效。直接、清晰、明了、KISS地表達意圖比玩編碼花招要重要…
避免去過問任何語言細節(jié)，除非必要。這個必要是指在實際編程當(dāng)中遇到問題，這樣就算需要過問細節(jié)，也是最省事的，懶惰者原則嘛。一個掌握了基本的編程理念并有較強學(xué)習(xí)能力的程序員在用一門陌生的語言編程時就算拿著那本語言的圣經(jīng)從索引翻起也可以編出合格的程序來。十年學(xué)會編程不是指對每門語言都得十年，那一輩子才能學(xué)幾門語言哪，如果按字母順序?qū)W的話一輩子都別指望學(xué)到Ruby了;十年學(xué)習(xí)編程更不是指先把語言特性從粗到細全都吃透才敢下手編程，在實踐中提高才是最重要的。
至于這種摳語言細節(jié)的哲學(xué)為何能在社群里面呈野火燎原之勢，就是一個心理學(xué)的問題了。想像人們在論壇上討論問題時，一個對語言把握很細致的人肯定能夠得到更多的佩服，而由于論壇上的問題大多是小問題，所以解決實際問題的真正能力并不能得到顯現(xiàn)，也就是說，知識型的人能夠得到更多佩服，后者便成為動力和仿效的砝碼。然而真正的編程能力是與語言細節(jié)沒關(guān)系的，熟練運用一門語言能夠幫你最佳表達你的意圖，但熟練運用一門語言絕不意味著要把它的邊邊角角全都記住。懂得一些常識，有了編程的基本直覺，遇到一些細節(jié)錯誤的時候再去查書，是最節(jié)省時間的辦法。
C++的書，Bjarne的圣經(jīng)《The C++ Programming Language》是高屋建瓴的。《大規(guī)模C++程序設(shè)計》是挺務(wù)實的。《Accelerated C++》是最佳入門的。《C++ Templates》是僅作參考的。《C++ Template Metaprogramming》是精力過剩者可以玩一玩的，普通程序員碰都別碰的。《ISO.IEC C++ Standard 14882》不是拿來讀的。Bjarne最近在做C++的教育，新書是絕對可以期待的。
P.S. 關(guān)于如何學(xué)習(xí)編程，g9的blog上有許多精彩的文章：這里，這里，這里，這里… 實際上，我建議你去把g9老大的blog翻個底朝天 :P
再P.S. 書單?我是遑于給出一個類似《C++初學(xué)者必讀》這種書單的。C++的書不計其數(shù)，被公認的好書也不勝枚舉。只不過有些書容易給初學(xué)者造成一種錯覺，就是“學(xué)習(xí)C++就應(yīng)該是這個樣子的”。比如有朋友提到的《高質(zhì)量C/C++編程》，這本書有價值，但不適合初學(xué)者，初學(xué)者讀這樣的書容易一葉障目不見泰山。實際上，正確的態(tài)度是，細節(jié)是必要的。但細節(jié)是次要的。其實學(xué)習(xí)編程我覺得應(yīng)該最先學(xué)習(xí)如何用偽碼表達思想呢，君不見《Introduction to Algorithm》里面的代碼?《TAOCP》中的代碼?哦，對了它們是自己建立的語言，但這種僅教學(xué)目的的語言的目的就是為了避免讓寫程序的人一開始就忘了寫程序是為了完成功能，以為寫程序就是和語言細節(jié)作斗爭了。Bjarne說程序的正確性最重要，boost的編碼標準里面也將正確性列在性能前面。
此外，一旦建立了正確的學(xué)習(xí)編程的理念，其實什么書(只要不是太垃圾的)都有些用處。都當(dāng)成參考書，用的時候從目錄或索引翻，基本就對了。
再再P.S. myan老大和g9老大都給出了許多精彩的見解。我不得不再加上一個P.S。具體我就不摘錄了，如果你讀到這里，請務(wù)必往下看他們的評論。轉(zhuǎn)載者別忘了轉(zhuǎn)載他們的評論:-)
許多朋友都問我同一個問題，到底要不要學(xué)習(xí)C++。其實這個問題問得很沒有意義。“學(xué)C++”和“不學(xué)C++”這個二分法是沒意義的，為什么?因為這個問題很表面，甚至很浮躁。重要的不是你掌握的語言，而是你掌握的能力，借用myan老大的話，“重要的是這個磨練過程，而不是結(jié)果，要的是你粗壯的腿，而不是你身上背的那袋鹽巴。”。此外學(xué)習(xí)C++的意義其實真的是醉翁之意不在酒，像C/C++這種系統(tǒng)級語言，在學(xué)習(xí)的過程中必須要涉及到一些底層知識，如內(nèi)存管理、編譯連接系統(tǒng)、匯編語言、硬件體系結(jié)構(gòu)等等等等知識(注意，這不包括過分犄角旮旯的語言枝節(jié))。這些東西也就是所謂的內(nèi)功了(其實最最重要的內(nèi)功還是長期學(xué)習(xí)所磨練出來的自學(xué)能力)。對此大嘴Joel在《Joel On Software》里面提到的漏洞抽象定律闡述得就非常漂亮。
所以，答案是，讓你成為高手的并不是你掌握什么語言，精通C++未必就能讓你成為高手，不精通C++也未必就能讓你成為低手。我想大家都不會懷疑g9老大如果要抄起C++做一個項目的話會比大多數(shù)自認熟練C++的人要做得漂亮。所以關(guān)鍵的不是語言這個表層的東西，而是底下的本質(zhì)矛盾。當(dāng)然，不是說那就什么語言都不要學(xué)了，按照一種曹操的邏輯，“天下語言，唯imperative與declarative耳”。C++是前者里面最復(fù)雜的一種，支持最廣泛的編程范式。借用當(dāng)初數(shù)學(xué)系入學(xué)大會上一個老師的話，“你數(shù)學(xué)都學(xué)了，還有什么不能學(xué)的呢?”。學(xué)語言是一個途徑，如果你把它用來磨練自己，可以。如果你把它用來作為學(xué)習(xí)系統(tǒng)底層知識的鑰匙，可以。如果你把它用來作為學(xué)習(xí)如何編寫優(yōu)秀的代碼，如何組織大型的程序，如何進行抽象設(shè)計，可以。如果掉書袋，光啃細節(jié)，我認為不可以(除非你必須要用到細節(jié)，像boost庫的coder們)。
然后再借用一下g9老大的《銀彈和我們的職業(yè)》中的話：
銀彈和我們的職業(yè)發(fā)展有什么相干?很簡單：我們得把時間用于學(xué)習(xí)解決本質(zhì)困難。新技術(shù)給高手帶來方便。菜鳥們卻不用指望被新技術(shù)拯救。沿用以前的比喻， 一流的攝影師不會因為相機的更新?lián)Q代而丟掉飯碗，反而可能借助先進技術(shù)留下傳世佳作。因為攝影的本質(zhì)困難，還是攝影師的藝術(shù)感覺。熱門技術(shù)也就等于相機。 不停追新，學(xué)習(xí)這個框架，那個軟件，好比成天鉆研不同相機的說明書。而熱門技術(shù)后的來龍去脈，才好比攝影技術(shù)。為什么推出這個框架?它解決了什么其它框架 不能解決的問題?它在哪里適用?它在哪里不適用?它用了什么新的設(shè)計?它改進了哪些舊的設(shè)計?Why is forever. 和 朋友聊天時提到Steve McConnell的《Professional Software Development》里面引了一個調(diào)查，說軟件開發(fā)技術(shù)的半衰期20年。也就是說20年后我們現(xiàn)在知識里一半的東西過時。相當(dāng)不壞。朋友打趣道：“應(yīng) 該說20年后IT界一半的技術(shù)過時，我們學(xué)的過時技術(shù)遠遠超過這個比例。具體到某人，很可能5年他就廢了”。話雖悲觀，但可見選擇學(xué)習(xí)內(nèi)容的重要性。學(xué)習(xí) 本質(zhì)技藝(技術(shù)遲早過時，技藝卻常用長新)還有一好處，就是不用看著自己心愛的技術(shù)受到挑戰(zhàn)的時候干嚎。C/C++過時就過時了唄，只要有其它的系統(tǒng)編程 語言。Java倒了就倒了唄，未必我不能用.net?Ruby曇花一現(xiàn)又如何。如果用得不爽，換到其它動態(tài)語言就是了。J2EE被廢了又怎樣?未必我們就 做不出分布系統(tǒng)了?這里還舉了更多的例子。
一句話，只有人是真正的銀彈。職業(yè)發(fā)展的目標，就是把自己變成銀彈。那時候，你就不再是人，而是人彈。
最后就以我在Bjarne的眾多訪談當(dāng)中摘錄的一些關(guān)于如何學(xué)習(xí)C++(以及編程)的看法結(jié)束吧(沒空逐段翻譯了，只將其中我覺得最重要的幾段譯了一下，當(dāng)然，其它也很重要，這些段落是在Bjarne的所有采訪稿中摘抄出來的，所以強烈建議都過目一下)：
I suspect that people think too little about what they want to build, too little about what would make it correct, and too much about "efficiency" and following fashions of programming style. The key questions are always: "what do I want to do?" and "how do I know that I have done if?". Strategies for testing enters into my concerns from well before I write the firat line of code, and that despite my view that you have to write code very early - rather than wait until a design is complete.
譯：我感覺人們過多關(guān)注了所謂“效率”以及跟隨編程風(fēng)格的潮流，卻嚴重忽視了本不該被忽視的問題，如“我究竟想要構(gòu)建什么樣的系統(tǒng)”、“怎樣才能使它正確”。最關(guān)鍵的問題永遠是：“我究竟想要做什么?”和“如何才能知道我的系統(tǒng)是否已經(jīng)完成了呢?”就拿我來說吧，我會在編寫第一行代碼之前就考慮測試方案，而且這還是在我關(guān)于應(yīng)當(dāng)早于設(shè)計完成之前就進行編碼的觀點的前提之下。
Obviously, C++ is very complex. Obviously, people get lost. However, most peple get lost when they get diverted into becoming language lawyers rather than getting lost when they have a clear idea of what they want to express and simply look at C++ language features to see how to express it. Once you know data absreaction, class hierarchies (object-oriented programming), and parameterization with types (generic programming) in a fairly general way, the C++ language features fall in place.
譯：誠然，C++非常復(fù)雜。誠然，人們迷失其中了。然而問題是，大多數(shù)人不是因為首先對自己想要表達什么有了清晰的認識只不過在去C++語言中搜尋合適的語言特性時迷失的，相反，大多數(shù)人是在不覺成為語言律師的路上迷失在細節(jié)的叢林中的。事實是，只需對數(shù)據(jù)抽象、類體系結(jié)構(gòu)(OOP)以及參數(shù)化類型(GP)有一個相當(dāng)一般層面的了解，C++紛繁的語言特性也就清晰起來了。
Well, I don't think I made such a trade-off. I want elegant and efficient code. Sometimes I get it. These dichotomies (between efficiency versus correctness, efficiency versus programmer time, efficiency versus high-level, et cetera.) are bogus.
I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grASPing at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.
Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just "sort of evolved" into something minimally acceptable. Personally, I prefer to know when a system will work, and why it will.
There are more useful systems developed in languages deemed awful than in languages praised for being beautiful--many more. The purpose of a programming language is to help build good systems, where "good" can be defined in many ways. My brief definition is, correct, maintainable, and adequately fast. Aesthetics matter, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably.
I'm sure that for every programmer that dislikes C++, there is one who likes it. However, a friend of mine went to a conference where the keynote speaker asked the audience to indicate by show of hands, one, how many people disliked C++, and two, how many people had written a C++ program. There were twice as many people in the first group than the second. Expressing dislike of something you don't know is usually known as prejudice. Also, complainers are always louder and more certain than proponents--reasonable people acknowledge flaws. I think I know more about the problems with C++ than just about anyone, but I also know how to avoid them and how to use C++'s strengths.
In any case, I don't think it is true that the programming languages are so difficult to learn. For example, every first-year university biology textbook contains more details and deeper theory than even an expert-level programming-language book. Most applications involve standards, operating systems, libraries, and tools that far exceed modern programming languages in complexity. What is difficult is the appreciation of the underlying techniques and their application to real-world problems. Obviously, most current languages have many parts that are unnecessarily complex, but the degree of those complexities compared to some ideal minimum is often exaggerated.
We need relatively complex language to deal with absolutely complex problems. I note that English is arguably the largest and most complex language in the world (measured in number of words and idioms), but also one of the most successful.
C++ provides a nice, extended case study in the evolutionary approach. C compatibility has been far harder to maintain than I or anyone else expected. Part of the reason is that C has kept evolving, partially guided by people who insist that C++ compatibility is neither necessary nor good for C. Another reason-- probably even more important--is that organizations prefer interfaces that are in the C/C++ subset so that they can support both languages with a single effort. This leads to a constant pressure on users not to use the most powerful C++ features and to myths about why they should be used "carefully," "infrequently," or "by experts only." That, combined with backwards-looking teaching of C++, has led to many failures to reap the potential benefits of C++ as a high-level language with powerful abstraction mechanisms.
The question is how deeply integrated into the application those system dependencies are. I prefer the application to be designed conceptually in isolation from the underlying system, with an explicitly defined interface to "the outer world," and then integrated through a thin layer of interface code.
Had I had a chance to name the style of programming I like best, it would have been "class-oriented programming", but then I'm not particularly good at finding snappy names. The school of thought that I belong to - rooted in Simula and related design philosophies - emphasizes the role of compile-time checking and flexible (static) type systems. Reasoning about the behavior of a program has to be rooted in the (static) structure of the source code. The focus should be on guarantees, invariant, etc. which are closely tied to that static structure. This is the only way I know to effectively deal with correctness. Testing is essential but cannot be systematic and complete without a good internal program structure - simple-minded blackbox testing of any significant system is infeasible because of the exponential explosion of states.
So, I recommend people to think in terms of class invariants, exception handling guarantees, highly structured resource management, etc. I should add that I intensely dislike debugging (as ah hoc and unsystematic) and strongly prefer reasoning about source code and systematic testing.
Pros: flexibility, generality, performance, portability, good tool support, available on more platforms than any competitor except C, Access to hardware and system resources, good availability of programmers and designers. Cons: complexity, sub-optimal use caused by poor teaching and myths.
?