我關於C和C++的一點觀點

 嗯，我昨天寫了一篇《我這一年》，表示最近有點時間了，能夠寫點博文了，網友們就很熱情，立刻在回帖中提問，其中有一篇比較引發我注意，就是和我討論個人書《0bug-C/C++商用工程之道》裏面對C和C++的應用比例和深度問題。

應該說，我本身一直定位仍是技術人員，我呢，也有興趣在關於技術方面展開一些討論，因此我暫時放下準備回覆的一些其餘朋友們的問題，先回答這個問題。

先立一個大前提，我無心引起語言之爭，在我心目中，各類語言無優劣之分，合用的就是最好的，不一樣意這個觀點的朋友，就沒必要向下看了。謝謝！

原文以下：

肖舸老師您好！
  我是一名在校計算機專業在校研究生，一直默默關注您的博客，您所寫的東西給了我莫大的幫助，開闊了很多視野。以前買了您的書《0 bug C/C＋＋商用工程之道》，目前閱讀了大概2/3，我以爲的書中的內容對我受益不淺，除了增加了經驗性質的東西，也學習了很多實用的之前未曾所知的技術，真的很是謝謝您！但願之後還能出這樣相似的好書！
學習歸學習，肖老師是業界的專家，而我只是初出茅廬的小鳥，不過我對肖老師書中的個別觀點不太苟同。肖老師C語言的功底很是深厚，可是對C＋＋的理解必定不夠深，或者說對面向對象的編程不夠深（至少在寫這本書以前）。肖老師鼓勵咱們不用多態、繼承等面向對象的高級特性，只是把C＋＋看成了一門多了封裝特性的C語言，開發方式上仍然是純面向過程的，這點至少這是本人從書中所看到的，我想肖老師那時確定沒看過關於設計模式方面的書吧，以致老是把C＋＋當作只是多了對象的C語言去用。《0 bug C/C＋＋商用工程之道》中講解到的基礎庫，由於都只是基礎功能性質的數據結構或庫，因此對面向對象的高級特性依賴很少，可是在開發實際應用層面上的東西或軟件架構時，面向對象的高級特性能有效下降系統的耦合性，加強系統可維護性。
  不過我仍然以爲《0 bug C/C＋＋商用工程之道》是一本不可多得的好書，我的只是不太苟同裏面對於C＋＋使用的觀點，這個純屬本身本人觀點。再次謝謝肖老師，但願能再讀到相似的好書！

個人回覆：

這位朋友你好，感謝你對我書的關注，關於你的問題，我能夠作一點說明和探討。

嗯，關於C和C++使用深度比例的問題，我贊成你的見解，我其實對C++瞭解並不深刻。對於你說的多態、繼承等面向對象的高級特性，理解不深入。設計模式也沒怎麼看。呵呵，是否是有點失望？

是這樣的，我是商業化程序員，從1995年我進入遊戲公司，正式成爲一個職業程序員開始，嗯，怎麼說呢，壓力一直在這麼多年伴隨着我，其中主要就是生存壓力。

瞭解個人朋友都知道，我原來是學習建築的，計算機軟件專業是半路出家，就是由於喜歡，因此我放棄之前國營單位的建築施工員職務，專門跑到成都一家公司打工，寫程序。

這種狀況下，我起點比別人低，又要在這個行業裏面生存，怎麼辦呢？

我首先要學習，以獲取足夠的職業技能，來知足工做的需求，否則就會被炒掉。但另外一方面，我也不可能像大學裏面的學生同樣，系統地學習，爲啥？我還得先寫出程序來，讓老闆賺到錢，我也才能領到個人薪水吃飯。

因此，個人學習，我想，社會上不少職業程序員的學習模型，大概都差很少，我概括就是「用以至學」。即用到哪塊知識，就惡補哪塊，很K書，多作實驗，多掌握一點細節特性，以便當即應用到工做中。

說個笑話，之前我基本上每找到一份工做，都須要惡補1~2個月，爲啥，由於工做機會這個東西，只有我將就他，不可能他將就我，若是他須要的知識我沒有，我就惡補，而後還要在之後的工做中，邊作邊學。

這樣作的好處和壞處都是顯而易見的：

壞處是我沒有通過系統的理論訓練，對於不少理論上已經定論的東西，不知道，非得本身試驗出來，才能深入瞭解。實際上，這是走了不少彎路，作了無用功。並且，我在工做中的用詞、用語習慣，和不少科班出生的人不同，你們溝通不容易。

但好處是咱們腦子裏面沒有條條框框，一個語言、一個技術，你們都說好，我未必說好，我喜歡本身來測試，看能不能帶到個人工做中有效幫助我，不行的就算了。而且，因爲不少試驗我不是聽人說的，而是本身作試驗的結果，因此不少東西很凌厲，實用性很強，對於解決實際工做中的問題，頗有幫助。

因此，這個問題我認爲見仁見智，還真說很差那個就是最優秀的，科班出身和實作出身，都能成才，也都有混不下去吃不上飯的。你說是不？

但我想有一點是最重要的，長期這麼堅持，我養成了一個習慣，就是「實踐是檢驗真理的惟一標準」，特別強調實驗法和方法論，不多去人云亦云。結合到咱們的軟件專業，我也總結出一句話，你看看能理解不：「計算機是檢驗程序的惟一標準」。

一個程序、一個語言，一門技術，你說好很差，沒用，我說好很差，也沒用，計算機說了算。我今天有個用戶需求，它知足了，而且開發起來多快好省，就是好東東，知足不了，說什麼都是假的。這就是我對技術的見解。呵呵，你看呢？

嗯，概括到C和C++語言上，我是這麼看得，兩個都是語言啦，它們和其餘Basic語言、彙編語言、C#、PHP、Java。。。等等，這些語言來講，並不具備什麼高貴之處，任何語言，能解決問題就是好語言。你們以爲呢？

我呢，前期從彙編入行，若是說我有面向過程的情節，我是贊成的，對於面向對象，我學了一點，能理解，夠用了，我以爲就行了，我畢竟不是語言專家，不須要對一門語言掌握到100分的。只要它能知足我程序開發需求就行了，這中間，還不能產生太大的學習成本，由於我不可能脫產幾個月去學習，那不用等我學好，工做就丟了，我也餓死了。呵呵。

可是，後來即便我薪水慢慢增高，已經有條件深刻研究C++這門語言的時候，其實我也沒有興趣去研究它了。

我想我說到重點了：爲何我沒有興趣去研究它？

我得說，是開發需求。

長期的程序生涯，我想不少職業程序員都會意識到一個問題，語言不重要、平臺不重要、技術不重要、算法不重要、數據結構不重要，全部這些，其實都不重要。

重要的是如何知足用戶需求。

在開發中，用戶需求變幻無窮，程序員若是不可以抽象需求的共性，而是疲於奔命地以項目制，就事論事的開發，本身的經驗技術沒有一個高效的積累，會累死的。

年輕時，咱們還能夠加班拼命，可是年紀大了呢？也和年輕人同樣加班？我今年快40了，這半年加班說實話本身以爲有點來不起了，如今還行，過個三五年，我也加不動了，那個時候怎麼辦？

這時候我想到了庫，即，可否經過對之前工做的概括和總結，爲本身總結出一套高效的、沒有多少bug的，能夠拿來就用的基本開發庫，經過對本身這個庫不斷地增補、優化、長期維護，來不斷支持本身之後的工做，使本身之後的工做愈來愈輕鬆，而不是每一個工做都從零開始，最後本身累死。

我後期的興趣主要就在這上面，因此，你們看見了《0bug-C/C++商用工程之道》這本書裏面的工程庫。

由於我以爲，這個庫的維護和精益求精，更能幫助我賺錢，而不是我去把C++語言背的倒背如流。

這裏我也奉勸學計算機軟件專業的學子，或者正在從事程序員這個職業的朋友，若是你想在這個行業裏面走得很遠，走一生，成爲專家級程序員，最好從如今開始，就準備本身的工程庫。只有有了這些沉澱和積累，你纔可能平安度過程序員35歲現象，寫程序寫到60歲去。嗯，這實際上是我我的的一個夢想，中國尚未多少60歲的程序員，我想作這種程序員。

總結庫不難的，一我的再跨行業，可是軟件專業有些通理是不變的，把這些總結下來，不斷根據新的需求調整，每次調整力求沒有bug，最終，會有一套真正屬於本身的庫的。

嗯，這個時候又有人說了，「不要作重複造輪子的事情！」，言下之意，只要這個世界上有了現成的庫，就徹底沒必要本身作無用功。

不知道你們怎麼看，我發現，說這話的，學校裏面的學生說最多，我也一直認爲，這裏面或多或少有點自我解釋，有點給本身偷懶找個理由的味道。

緣由很簡單，之後你們走到工做崗位，面臨的機器、平臺、需求變幻無窮，每一個庫在寫的過程當中，都是開發者憑想象在預估將來的需求，總有不知足之處，若是一我的，只會依靠現成的庫來寫程序，嗯，若是有一天沒庫給你用了，你怎麼辦？

我不敢想，起碼，我本身不敢作這種程序員。

事實上，走上工做崗位的程序員，很少，1~2年，我想必定就會碰到找不到現成庫來用的狀況。

個人感受，大多數庫在大多數時候都是無用的。

怎麼辦？本身來咯。

舉幾個例子吧，就說我最近作實時數據庫的問題。

二分法你們知道吧，我想這種算法是高校裏面最喜歡研究的，也是庫最多的。

咱們面臨的狀況比較特殊，二分法可能查找時間點，可能匹配時間段，也可能去一個數序中模糊檢索一個偏移位置，而後決定是否再進一步精細查找。。。。還有不少特殊的應用需求。

最變態的，咱們須要二分法給我反三，即最後模糊查到最靠近的三個元素，並論述咱們標定的查詢條件在三個元素的相對關係。

還有就是咱們要求送進去的多是幾種結構體，也多是一個浮點數表示的時間點，還有多是一個包容了某個時間戳的一個大型結構體。

還有返回值，可能咱們須要一個精確的index，一個反三的報告，或者一個時間段與時間段比較的兩重報告。

這些都是應用需求。

怎麼辦？本身寫咯。

最後咱們光二分法開發出好幾個模塊，嗯，並且基本上都是純C的，沒用C++，爲啥，這一個純方法，沒有實體數據，我確實想不出有什麼封裝的必要，面向對象，這個對象的定義若是我沒有記錯的話，是一堆數據以及其方法的集合，數據都沒有，咋封裝？

封裝一個類，裏面全是靜態函數？那我還真不如用純C完成。

還有樹，咱們玩來玩去，最後作了一個很是奇怪的結構，甚至咱們都不知道它算不算樹，一個雙向鏈表，上層還有另一個雙向鏈表，兩者每一個元素之間還彼此耦合，以便得到檢索尋路的最大方便性，你們想象一下火車的鐵路橋，有那種加固鋼架那種，咱們就是那種結構。

這也是本身努力分析了半天，學習了國外不少先進經驗以後，定義出來的一套核心數據組織架構，最後證實，咱們這套架構比較科學，我寫了一套檢索算法，自動優選路由，也就300行代碼左右，最多遍歷40幾個塊，就能精肯定位一筆數據。

這意味着什麼？在服務器上，個人cache每秒鐘能吞吐125萬塊左右，除去寫入的20萬塊，我還有100萬塊地交換能力，除以40，我每秒鐘能承接2500路併發查詢請求。目前國內外最高的才500，你們以爲我這麼寫程序，能不能賺到錢？

說到cache，嗯，LRU算法，你們可能學得多了，我想這方面的庫不少，可是，咱們從一開始就沒打算用庫，爲啥？效率。

全部的LRU算法，基本上都是雙向鏈表，OK，多任務環境下，要不要加鎖？不加就崩掉了。

若是用別人的庫，我就只能在外面加一把大鎖，即每一個塊被訪問時，是排他的，cache同時只能支撐一個塊被訪問，這麼作固然沒問題，就是賺不到錢了。程序效率太爛了。

那怎麼辦？我本身想了一個辦法，也作了一些斷言和推論，最後讓cache本身就變成一把單寫多讀鎖，針對每一個塊分別加鎖，實現了這個需求，這個，但是找不到庫的。也就是由於我這麼設計，你們覺得前面每秒125萬塊的交換能力怎麼來的？呵呵。

嗯，就這麼幾個例子，你們以爲能說明問題不？

好吧，最後仍是要回歸到C和C++的討論，總結一下吧。

我認爲，對於語言，學校中的學習需求和實際中的應用需求，並不徹底一致。

學校裏面是「學以至用」，老師沒法預估到你們之後從事何種行業，何種工做，所以，必須把一門語言全部的特性都交給你們，還要考試，所以對於一門語言學習的廣度和深度，很好，可是，如何在之後的應用中，巧妙地利用語言的某個特性，來解決實際中的問題，這個沒有講。甚至不少老師本身都不知道。

實際中呢，是「用以至學」，可能對一門語言，一門技術不求精準，特別強調實用性，這個呢，能有效解決問題，可是因爲缺少理論支撐，容易走彎路。浪費不少無用功，不少沒必要要的加班。

最好呢，是兩者結合，即在學校中努力學習，理論掌握儘可能紮實，之後到了實際中呢，也不要帶着太多的偏見、成見，虛心學習不少別人的竅門、經驗、實用技術，同時善於總結概括，不斷造成本身獨有的一些開發思想體系，方能成才。

至於把C++當作多了對象的C語言用，沒有用到它的高端特性，我想既然這麼多年，它擔任這個角色挺好，在我庫中和工做中，也挺合適，那就讓它繼續作下去吧。呵呵，否則，個人書就不是C/C++商用工程之道了，而是《0bug-C語言商用工程之道》了。

呵呵。

嗯，這樣回覆你還滿意嗎？

肖舸