非常好的文章，這纔是用C++的正確方式，怕作者某天刪掉了，轉到自己帳下！
----------------------------------------------------------------------------------------------------------------------------------------------------------
昨天晚上看到劉江的blog又補充了好幾大段，今天早上又看到雲風的人肉trackback，果然還是這種話題引人關注。
雲風先是提了一下所謂C++帶來的思想包袱（文言文曰“心智包袱”）問題，然後重重地引用了Linus的話：“關鍵是設計”，其實他是在暗示：好的設計C同樣能做出來，不勞C++大駕；而C++一旦出面，就要讓人背上額外的思想包袱。
我明確地表個態，在系統級程序設計中，事實就是這樣的。
別小看這個思想包袱，大部分，甚至絕大部分C++程序員過不了這一關。相反，做系統級開發，C是幾乎沒有思想包袱的語言，說白了就是刺刀見紅，你想要啥你就去寫啥，它給你的不多也不少，沒什麼幹不了，也沒什麼非讓你揹着不可。
我早在N年前就發現自己寫程序速度慢，我當時對STL遠比周圍人熟悉，照例說長纓在手，應該效率 很高才對。結果發現不是，寫程序的時候特別沒自信，總在想：“這樣固然是可以work了，但恐怕有更好的方案吧，會是什麼呢？加個模板參數試試？要麼抽象 出一個基類？做一個bridge模式？那麼Ownership的問題怎麼解決？誰 來負責回收內存呢？移植一個boost::shared_ptr過來吧！可多線程情況下會不會拖慢速度呢？應該不會，可是會碰到循環引用的情況。要麼在中 間搞一個weak_ptr把循環鏈斷開？哎呀不行不行，太複雜，別人也理解不了。還是先這樣吧，能work就行。” 就這樣，兜了一個圈子回來。有的時候，這個圈子不是純柏拉圖式的，我會真的實現不少 “優化” 設計來比對，那個時間啊，花花的就耗在裏面了。有的時候確實會獲得一些改進，但是多數時候是得不償失，旁邊那些在我看來連C都只是一知半解的傢伙採用 “CtrlC-CtrlV-Modify-Debug” 大法，早就衝到我前頭去了。這就是“心智包袱”的威力。
最近幾年沒怎麼用C++寫程序，業餘時間倒是別的語言用了好幾種。大概是體會到這些語言的某些好處之後，對C++就能看得更客觀一些了，也琢磨了一下，如 果自己有朝一日重新跑回去寫C/C++，我會怎麼幹？畢竟現在C++程序員全球緊缺，工資越來越高，這個問題還是有其現實意義的。正好昨天跟chensh 聊了一會兒，兩個人的看法一致，就是採取“ C + Concreate Class + STL”的風格。說白了就是用C來設計，用C++來編碼。
這裏面的道理是這樣的，反正現在C和C++都是來做系統級開發，那些華麗的抽象機制用不上，思考解決方案的時候，就以C的方式。注意，C也是可以做基於對 象甚至面向對象甚至組件級別的設計的，但是在C的層面上思考問題，設計能夠更精益（lean，現在這是個時髦詞），更輕便，更直接。當你構思的設計方案出 來以後，如果其中有些部分，恰好是C++現成做好了，而且使用C++又可以提高開發效率，也沒什麼明顯的副作用，那麼就用C++來做相應的部分。比如， COM原來設計的時候就是在C基礎上做的，設計的時候發現實際上跟C++實現多態的的vptr + vtable是吻合的，所以後來就主要用C++來做COM開發。事實上，爲了適應COM開發的需要，微軟直接改了C++編譯器。很顯然，微軟是首先構思好 的設計，然後讓C++去適應這個設計。而後來很多C++程序員，是讓設計去適應C++的那些語言機制，在系統開發中，這個叫做本末倒置。當然這樣的事情在 應用級別上就不是那麼離譜。
實際上回頭看看C++早期的歷史，最早C++就是把一些C中常用的patterns內置到語言裏而出現的，早期它曾經有效地提高了開發效率。今天應該回頭去尋找這種精神。
我支持STL是基於同樣的理由。很多時候，你從C出發得到的設計，也無非就是STL已經實現得很好的東西。在這個時候，當然可以用STL。尤其是那些算 法，針對C array也是適用的，用accumulate求和，用transform映射，用adjacent_find尋找相等的毗鄰項，用 lower_bound和equal_range做二分查找，等等，這不是比手寫要爽多了嗎？當然，使用STL，還是必須熟悉其背後的機理，沒有這個底 子，還是規規矩矩用C算了。