初學(xué)者,你應(yīng)當(dāng)如何學(xué)習(xí)C++以及編程.doc

初學(xué)者,你應(yīng)當(dāng)如何學(xué)習(xí)C+以及編程初學(xué)者，你應(yīng)當(dāng)如何學(xué)習(xí)C+以及編程 軟件小兵ruanjianxiaobingsohu作者：未知 文章來源：天極Yesky軟件頻道 Javascript是世界上最受誤解的語言，其實(shí)C+何嘗不是。坊間流傳的錯(cuò)誤的C+學(xué)習(xí)方法一抓就是一大把。我自己在學(xué)習(xí)C+的過程中也走了許多彎路，浪費(fèi)了不少時(shí)間。為什么會(huì)存在這么多錯(cuò)誤認(rèn)識(shí)?原因主要有三個(gè)，一是C+語言的細(xì)節(jié)太多。二是一些著名的C+書籍總在(不管有意還是無意)暗示語言細(xì)節(jié)的重要性和有趣。三是現(xiàn)代C+庫的開發(fā)哲學(xué)必須用到一些犄角旮旯的語言細(xì)節(jié)(但注意，是庫設(shè)計(jì)，不是日常編程)。這些共同塑造了C+社群的整體心態(tài)和哲學(xué)。單是第一條還未必能夠成氣候，其它語言的細(xì)節(jié)也不少(盡管比起C+起來還是小巫見大巫)，就拿Javascript來說，作用域規(guī)則，名字查找，closure，for/in，這些都是細(xì)節(jié)，而且其中還有違反直覺的。但許多動(dòng)態(tài)語言的程序員的理念我猜大約是學(xué)到哪用到哪罷。但C+就不一樣了，學(xué)C+之人有一種類似于被暗示的潛在心態(tài)，就是一定要先把語言核心基本上吃透了才能下手寫出漂亮的程序。這首先就錯(cuò)了。這個(gè)意識(shí)形成的原因在第二點(diǎn)，C+書籍。市面上的C+書籍不計(jì)其數(shù)，但有一個(gè)共同的缺點(diǎn)，就是講語言細(xì)節(jié)的書太多C+ gotchas，Effective C+，More Effective C+，但無可厚非的是，C+是這樣一門語言：要拿它滿足現(xiàn)代編程理念的需求，尤其是C+庫開發(fā)的需求，還必須得關(guān)注語言細(xì)節(jié)，乃至于在C+中利用語言細(xì)節(jié)已經(jīng)成了一門學(xué)問。比如C+模板在設(shè)計(jì)之初根本沒有想到模板元編程這回事，更沒想到C+模板系統(tǒng)是圖靈完備的，這也就導(dǎo)致了Modern C+ Design和C+ Template Metaprogramming的驚世駭俗。這些技術(shù)的出現(xiàn)為什么驚世駭俗，打個(gè)比方，就好比是一塊大家都認(rèn)為已經(jīng)熟悉無比，再無秘密可言的土地上，突然某天有人挖到原來地下還蘊(yùn)藏著最豐富的石油。在這之前的C+雖然也有一些細(xì)節(jié)，但也還算容易掌握，那可是C+程序員們的happy old times，因?yàn)镃+的一切都一覽無余，everything is figured out。然而Modern C+ Design的出世告訴人們，“瞧，還有多少細(xì)節(jié)你們沒有掌握啊?！庇谑荂+程序員們久違的激情被重燃起來，奮不顧身的踏入細(xì)節(jié)的沼澤中。尤其是，模板編程將C+的細(xì)節(jié)進(jìn)一步挖掘到了極致我們干嘛關(guān)心涉及類對(duì)象的隱式轉(zhuǎn)換的優(yōu)先級(jí)高低?看看boost:is_base_of就可以知道有多詭異了。但最大的問題還在于，對(duì)于這些細(xì)節(jié)的關(guān)注還真有它合適的理由：我們要開發(fā)現(xiàn)代模板庫，要開發(fā)active library，就必須動(dòng)用模板編程技術(shù)，要?jiǎng)佑媚０寰幊碳夹g(shù)，就必須利用語言的犄角旮旯，enable_if，type_traits，甚至連早就古井無波的C宏也在亂世中重生，看看boost:preprocessor有多詭異就知道了，連C宏的圖靈完備性(預(yù)編譯期的)都被挖掘出來了。為什么要做這些?好玩?標(biāo)榜?都不是，開發(fā)庫的實(shí)際需求。但這也正是最大的悲哀了。在boost里面因?qū)嶋H需求而動(dòng)用語言細(xì)節(jié)最終居然能神奇的完成任務(wù)的最好教材就是boost:foreach，這個(gè)小設(shè)施對(duì)語言細(xì)節(jié)的發(fā)掘達(dá)到了驚天地泣鬼神的地步，不信你先試著自己去看看它的源代碼，再看看作者介紹它的文章吧。而boost:typeof也不甘其后C+語言里面有太多被“發(fā)現(xiàn)”而不是被“發(fā)明”的技術(shù)。難道最初無意設(shè)置這些語言規(guī)則的家伙們都是Oracles?因?yàn)闆]有variadic templates，人們用宏加上缺省模板參數(shù)來實(shí)現(xiàn)類似效果。因?yàn)闆]有concepts，人們用模板加上析構(gòu)函數(shù)的細(xì)節(jié)來完成類似工作。因?yàn)闆]有typeof，人們用模板元編程和宏加上無盡的細(xì)節(jié)來實(shí)現(xiàn)目標(biāo) C+開發(fā)者們的DIY精神不可謂不強(qiáng)。然而，如果僅僅是因?yàn)橐_發(fā)優(yōu)秀的庫，那么涉及這些細(xì)節(jié)都還是情有可原的，至少在C+09出現(xiàn)并且編譯器廠商跟上之前，這些都還能說是不得已而為之。但我們廣大的C+程序員呢?大眾是容易被誤導(dǎo)的，我也曾經(jīng)是。以為掌握了更多的語言細(xì)節(jié)就更牛，但實(shí)際卻是那些語言細(xì)節(jié)十有八九是平時(shí)編程用都用不到的。C+中眾多的細(xì)節(jié)雖然在庫設(shè)計(jì)者手里面有其用武之地，但普通程序員則根本無需過多關(guān)注，尤其是沒有實(shí)際動(dòng)機(jī)的關(guān)注。一般性的編碼實(shí)踐準(zhǔn)則，以及基本的編程能力和基本功，乃至基本的程序設(shè)計(jì)理論以及算法設(shè)計(jì)。才是真正需要花時(shí)間掌握的東西。學(xué)習(xí)最佳編碼實(shí)踐比學(xué)習(xí)C+更重要?？磧?yōu)秀的代碼也比埋頭用差勁的編碼方式寫垃圾代碼要有效。直接、清晰、明了、KISS地表達(dá)意圖比玩編碼花招要重要避免去過問任何語言細(xì)節(jié)，除非必要。這個(gè)必要是指在實(shí)際編程當(dāng)中遇到問題，這樣就算需要過問細(xì)節(jié)，也是最省事的，懶惰者原則嘛。一個(gè)掌握了基本的編程理念并有較強(qiáng)學(xué)習(xí)能力的程序員在用一門陌生的語言編程時(shí)就算拿著那本語言的圣經(jīng)從索引翻起也可以編出合格的程序來。十年學(xué)會(huì)編程不是指對(duì)每門語言都得十年，那一輩子才能學(xué)幾門語言哪，如果按字母順序?qū)W的話一輩子都別指望學(xué)到Ruby了;十年學(xué)習(xí)編程更不是指先把語言特性從粗到細(xì)全都吃透才敢下手編程，在實(shí)踐中提高才是最重要的。至于這種摳語言細(xì)節(jié)的哲學(xué)為何能在社群里面呈野火燎原之勢(shì)，就是一個(gè)心理學(xué)的問題了。想像人們?cè)谡搲嫌懻搯栴}時(shí)，一個(gè)對(duì)語言把握很細(xì)致的人肯定能夠得到更多的佩服，而由于論壇上的問題大多是小問題，所以解決實(shí)際問題的真正能力并不能得到顯現(xiàn)，也就是說，知識(shí)型的人能夠得到更多佩服，后者便成為動(dòng)力和仿效的砝碼。然而真正的編程能力是與語言細(xì)節(jié)沒關(guān)系的，熟練運(yùn)用一門語言能夠幫你最佳表達(dá)你的意圖，但熟練運(yùn)用一門語言絕不意味著要把它的邊邊角角全都記住。懂得一些常識(shí)，有了編程的基本直覺，遇到一些細(xì)節(jié)錯(cuò)誤的時(shí)候再去查書，是最節(jié)省時(shí)間的辦法。C+的書，Bjarne的圣經(jīng)The C+ Programming Language是高屋建瓴的。大規(guī)模C+程序設(shè)計(jì)是挺務(wù)實(shí)的。Accelerated C+是最佳入門的。C+ Templates是僅作參考的。C+ Template Metaprogramming是精力過剩者可以玩一玩的，普通程序員碰都別碰的。ISO.IEC C+ Standard 14882不是拿來讀的。Bjarne最近在做C+的教育，新書是絕對(duì)可以期待的。P.S. 關(guān)于如何學(xué)習(xí)編程，g9的blog上有許多精彩的文章：這里，這里，這里，這里 實(shí)際上，我建議你去把g9老大的blog翻個(gè)底朝天 :P再P.S. 書單?我是遑于給出一個(gè)類似C+初學(xué)者必讀這種書單的。C+的書不計(jì)其數(shù)，被公認(rèn)的好書也不勝枚舉。只不過有些書容易給初學(xué)者造成一種錯(cuò)覺，就是“學(xué)習(xí)C+就應(yīng)該是這個(gè)樣子的”。比如有朋友提到的高質(zhì)量C/C+編程，這本書有價(jià)值，但不適合初學(xué)者，初學(xué)者讀這樣的書容易一葉障目不見泰山。實(shí)際上，正確的態(tài)度是，細(xì)節(jié)是必要的。但細(xì)節(jié)是次要的。其實(shí)學(xué)習(xí)編程我覺得應(yīng)該最先學(xué)習(xí)如何用偽碼表達(dá)思想呢，君不見Introduction to Algorithm里面的代碼?TAOCP中的代碼?哦，對(duì)了它們是自己建立的語言，但這種僅教學(xué)目的的語言的目的就是為了避免讓寫程序的人一開始就忘了寫程序是為了完成功能，以為寫程序就是和語言細(xì)節(jié)作斗爭了。Bjarne說程序的正確性最重要，boost的編碼標(biāo)準(zhǔn)里面也將正確性列在性能前面。此外，一旦建立了正確的學(xué)習(xí)編程的理念，其實(shí)什么書(只要不是太垃圾的)都有些用處。都當(dāng)成參考書，用的時(shí)候從目錄或索引翻，基本就對(duì)了。再再P.S. myan老大和g9老大都給出了許多精彩的見解。我不得不再加上一個(gè)P.S。具體我就不摘錄了，如果你讀到這里，請(qǐng)務(wù)必往下看他們的評(píng)論。轉(zhuǎn)載者別忘了轉(zhuǎn)載他們的評(píng)論:-)許多朋友都問我同一個(gè)問題，到底要不要學(xué)習(xí)C+。其實(shí)這個(gè)問題問得很沒有意義。“學(xué)C+”和“不學(xué)C+”這個(gè)二分法是沒意義的，為什么?因?yàn)檫@個(gè)問題很表面，甚至很浮躁。重要的不是你掌握的語言，而是你掌握的能力，借用myan老大的話，“重要的是這個(gè)磨練過程，而不是結(jié)果，要的是你粗壯的腿，而不是你身上背的那袋鹽巴?！?。此外學(xué)習(xí)C+的意義其實(shí)真的是醉翁之意不在酒，像C/C+這種系統(tǒng)級(jí)語言，在學(xué)習(xí)的過程中必須要涉及到一些底層知識(shí)，如內(nèi)存管理、編譯連接系統(tǒng)、匯編語言、硬件體系結(jié)構(gòu)等等等等知識(shí)(注意，這不包括過分犄角旮旯的語言枝節(jié))。這些東西也就是所謂的內(nèi)功了(其實(shí)最最重要的內(nèi)功還是長期學(xué)習(xí)所磨練出來的自學(xué)能力)。對(duì)此大嘴Joel在Joel On Software里面提到的漏洞抽象定律闡述得就非常漂亮。所以，答案是，讓你成為高手的并不是你掌握什么語言，精通C+未必就能讓你成為高手，不精通C+也未必就能讓你成為低手。我想大家都不會(huì)懷疑g9老大如果要抄起C+做一個(gè)項(xiàng)目的話會(huì)比大多數(shù)自認(rèn)熟練C+的人要做得漂亮。所以關(guān)鍵的不是語言這個(gè)表層的東西，而是底下的本質(zhì)矛盾。當(dāng)然，不是說那就什么語言都不要學(xué)了，按照一種曹操的邏輯，“天下語言，唯imperative與declarative耳”。C+是前者里面最復(fù)雜的一種，支持最廣泛的編程范式。借用當(dāng)初數(shù)學(xué)系入學(xué)大會(huì)上一個(gè)老師的話，“你數(shù)學(xué)都學(xué)了，還有什么不能學(xué)的呢?”。學(xué)語言是一個(gè)途徑，如果你把它用來磨練自己，可以。如果你把它用來作為學(xué)習(xí)系統(tǒng)底層知識(shí)的鑰匙，可以。如果你把它用來作為學(xué)習(xí)如何編寫優(yōu)秀的代碼，如何組織大型的程序，如何進(jìn)行抽象設(shè)計(jì)，可以。如果掉書袋，光啃細(xì)節(jié)，我認(rèn)為不可以(除非你必須要用到細(xì)節(jié)，像boost庫的coder們)。然后再借用一下g9老大的銀彈和我們的職業(yè)中的話： 銀彈和我們的職業(yè)發(fā)展有什么相干?很簡單：我們得把時(shí)間用于學(xué)習(xí)解決本質(zhì)困難。新技術(shù)給高手帶來方便。菜鳥們卻不用指望被新技術(shù)拯救。沿用以前的比喻， 一流的攝影師不會(huì)因?yàn)橄鄼C(jī)的更新?lián)Q代而丟掉飯碗，反而可能借助先進(jìn)技術(shù)留下傳世佳作。因?yàn)閿z影的本質(zhì)困難，還是攝影師的藝術(shù)感覺。熱門技術(shù)也就等于相機(jī)。 不停追新，學(xué)習(xí)這個(gè)框架，那個(gè)軟件，好比成天鉆研不同相機(jī)的說明書。而熱門技術(shù)后的來龍去脈，才好比攝影技術(shù)。為什么推出這個(gè)框架?它解決了什么其它框架 不能解決的問題?它在哪里適用?它在哪里不適用?它用了什么新的設(shè)計(jì)?它改進(jìn)了哪些舊的設(shè)計(jì)?Why is forever. 和 朋友聊天時(shí)提到Steve McConnell的Professional Software Development里面引了一個(gè)調(diào)查，說軟件開發(fā)技術(shù)的半衰期20年。也就是說20年后我們現(xiàn)在知識(shí)里一半的東西過時(shí)。相當(dāng)不壞。朋友打趣道：“應(yīng) 該說20年后IT界一半的技術(shù)過時(shí)，我們學(xué)的過時(shí)技術(shù)遠(yuǎn)遠(yuǎn)超過這個(gè)比例。具體到某人，很可能5年他就廢了”。話雖悲觀，但可見選擇學(xué)習(xí)內(nèi)容的重要性。學(xué)習(xí) 本質(zhì)技藝(技術(shù)遲早過時(shí)，技藝卻常用長新)還有一好處，就是不用看著自己心愛的技術(shù)受到挑戰(zhàn)的時(shí)候干嚎。C/C+過時(shí)就過時(shí)了唄，只要有其它的系統(tǒng)編程 語言。Java倒了就倒了唄，未必我不能用.NET?Ruby曇花一現(xiàn)又如何。如果用得不爽，換到其它動(dòng)態(tài)語言就是了。J2EE被廢了又怎樣?未必我們就 做不出分布系統(tǒng)了?這里還舉了更多的例子。一句話，只有人是真正的銀彈。職業(yè)發(fā)展的目標(biāo)，就是把自己變成銀彈。那時(shí)候，你就不再是人，而是人彈。最后就以我在Bjarne的眾多訪談當(dāng)中摘錄的一些關(guān)于如何學(xué)習(xí)C+(以及編程)的看法結(jié)束吧(沒空逐段翻譯了，只將其中我覺得最重要的幾段譯了一下，當(dāng)然，其它也很重要，這些段落是在Bjarne的所有采訪稿中摘抄出來的，所以強(qiáng)烈建議都過目一下)：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)格的潮流，卻嚴(yán)重忽視了本不該被忽視的問題，如“我究竟想要構(gòu)建什么樣的系統(tǒng)”、“怎樣才能使它正確”。最關(guān)鍵的問題永遠(yuǎn)是：“我究竟想要做什么?”和“如何才能知道我的系統(tǒng)是否已經(jīng)完成了呢?”就拿我來說吧，我會(huì)在編寫第一行代碼之前就考慮測(cè)試方案，而且這還是在我關(guān)于應(yīng)當(dāng)早于設(shè)計(jì)完成之前就進(jìn)行編碼的觀點(diǎn)的前提之下。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ù)人不是因?yàn)槭紫葘?duì)自己想要表達(dá)什么有了清晰的認(rèn)識(shí)只不過在去C+語言中搜尋合適的語言特性時(shí)迷失的，相反，大多數(shù)人是在不覺成為語言律師的路上迷失在細(xì)節(jié)的叢林中的。事實(shí)是，只需對(duì)數(shù)據(jù)抽象、類體系結(jié)構(gòu)(OOP)以及參數(shù)化類型(GP)有一個(gè)相當(dāng)一般層面的了解，C+紛繁的語言特性也就清晰起來了。Well, I dont 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-its 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.Im 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 dont 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 dont 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 Im not particularly good at finding snappy names. The school of thought that I belong to - rooted in Simula and related design philosophie