C++是一門很神奇的語言，讓人又愛又恨。
在知乎上看到的一個帖子，怎麼樣才算是精通C++，這裡節選一些精彩的回復。
1
精通C++是一個艱巨的任務。為什麼C++比別的語言難學這麼多？其實這基本上是因為C++他爹Bjarne Stroustrup說過的一句話“我特別討厭語言的設計者把自己的喜好強加給用戶”（看向go）。結果C++為了不限制你的想法，於是也就變成了現在這個樣子——包含若干范式，大概有面向對象（靈活應用virtual繼承+shared_ptr可以達到java/C#的效果）模板（這裡分兩類，分別為type rich programming和meta programming，區別很大）函數式編程（如今有了lambda，配合文件，簡直無敵了）過程式但是難能可貴的是，這幾種東西在C++混在一起用也是多麼的自然。不過，這需要你花時間去掌控他。那到底有沒有必要真的學到這個地步呢，我覺得跟你的領域是有關系的。譬如說我，基本上算是人格分裂的，因為：當我搞語言設計和編譯器的時候，我總是會傾向於創造各種小DSL來給自己用，用的都是模板（想想boost的spirit大概就明白我的意思了，雖然我不用它），盡量讓跟我有同樣背景的人一眼能看懂我代碼的意思。當我做我那個GUI庫（www.gaclib.net）的時候，純粹是用OO和IoC那一套。當我寫3D渲染程序的時候，我會變成一個為了性能不惜犧牲可讀性的人。當我是不同的我的時候，我當然只會用C++的一部分來完成我當前的這個任務。這好像是多重標准，但是實際上是由於項目本身的性質而定的。到了這個時候你會覺得，C++真是一門好語言。當你需要為了你的項目放棄不同的部分的時候，C++都能幫你做到。當你需要不同的抽象層次需要不同的性能要求的是，C++還是能夠幫你做到。如果你用別的語言，你最終會發現那個語言只能做某幾類的項目。這是因為，C++能夠自由的讓你放棄某些部分，而別的語言會阻止你放棄某些部分。為了達到這個層次，你必須進入一個無限接近於精通C++的狀態裡，這個時候你才能收放自如，不被C++社區的各種不同的價值觀所捆綁。倘若你的項目非常大，不同的部分有不同的特征的時候（什麼，一個沒有遍布全世界的一兩千人寫了20年的程序能叫程序嗎？），就更加需要你有這種本事了。說到這裡，大家大概都明白精通C++大概是個什麼感覺了吧——大丈夫能屈能伸。
2
谷歌工程師對C++的掌握有兩個級別：
擁有C++的readability（可讀性）認證。通過這個認證需要在實際工作中寫出一個比較復雜的完整的類，然後將這個類提交到一個委員會進行審查，委員會會幫你糾正常見的錯誤，如果你的這個類滿足style guide[1]的所有要求，一兩個星期之後你就可以拿到可讀性認證。一般來說，你需要在實際工作中寫過至少幾千行代碼才能達到這個要求。C++的readability對工程師的意義主要有兩個，一個是熟悉並避免C++的缺陷（比如不要使用iostream和exception），另一個是熟悉一些常用的庫函數（比如string的各種操作，hash_map和smart pointer的使用等）。通過這個認證之後，工程師就有權利在code review中審閱其他人寫的C++程序（注意這個不是readability review）。絕大多數工程師對C++的掌握處在這個水平。
顧問級C++程序員。一般需要寫過數萬行C++代碼，用C++實現過比較復雜的系統，熟悉常見的設計模式並在實際工作中應用，對代碼重構有豐富經驗，最重要的是，成為小組以及周圍同事的C++顧問，是同事有C++使用問題時最先想到詢問的人。顧問級C++程序員通常是高級工程師（senior engineer）及以上級別，不僅對某種程序語言，對工作中的各種工程問題也經驗豐富。其實“精通C++”並不僅僅是熟悉C++本身，你需要對C++需要實現的工程問題和周邊問題同樣精通；而且“精通C++”這種說法是相對的，如果你能成為組裡的C++顧問，能夠幫助同事正確使用這種語言有效率地解決工程問題並避免C++的誤區，你就算是精通C++的那個人。
3
Never trust a programmer who says he knows C++
源碼。其它的，我覺得實用性不強了，去摳語言的細節，語言的實現等，那不叫精通了。那是神通了，反正我認識的技術牛人，人家是去摳系統，原理上的細節，很少去扣語言的，本來語言就是一個工具，用好他，壞了能簡單的維護，管他是怎麼實現的。
