學好c++，是不是最好研究下其編譯器？因為感覺c++的編譯器做了很多僅從語言前端看不出的工作。?

01-12

我覺得我比較有資格來回答這個問題，因為我是抱著這個想法，然後走到編譯器這條路上來的，也加入了IBM開發C++編譯器。當然按照我司的一些規章制度，首先聲明一下，以下僅代表我的個人看法，與IBM無關。

我算是C++腦殘粉一個吧，而讓我走上C++腦殘粉這條路的直接導火線是這一本書：C++語言的設計與演化 (豆瓣)，之前我雖然也用著C++，也用的不太爽，也無腦黑C++，然後那個時候用Java做著Android項目，做著Java EE，感嘆說這才是好語言，哪像C++那麼多坑。然而讀了這本書，才發現原來這些坑到底是怎麼來的，而有關哲學的那些部分寫的更加讓我愛不釋手，於是我也開始重新再來看C++，而重新再看C++的時候，雖然知道了那些坑來的原因，但是自己卻不知道編譯器到底是如何解決這些問題的，這裡面蘊含的神奇東西實在太多，我也很想一探究竟。

於是，後來我有機會從事C++編譯器工作開發了，我打開了這個黑匣子，可以追尋這裡面的奧秘了。而當我打開這個黑匣子後，我發現我確實對C++很多特性理解更清楚了。如我知道了Object Model，Exception Handling，Template等等在編譯器是如何做的，是的，這裡面很多的東西在編譯器裡面的流程很複雜，然而對於C++開發者來說這是否必須呢？我認為很多很多很多的東西都是完全是不需要的，如你知道Template的編譯流程，是否就會讓你在Template Programming這一塊兒有很大的功力見長呢，然後一下就會Template Meta Programming呢？這肯定是不可能的。所以，對於提高C++能力來說，或許你去實現STL都來的更快。

那麼，研究C++編譯器的好處又是什麼呢？我想就是知其然的感覺。因為知道了很多東西，於是在一些C++的問題上，容易知道在哪裡出問題。如在模板問題上，因為知道了整個流程，所以即使編譯器報再詭異的錯誤，或者編譯器與編譯器之間的不同行為時，也知道如何去避免。因為在做編譯器的時候，你會讀標準，你會去比較不同的編譯器的行為，你會知道如何可以讓編譯器掛掉，你會知道發生Internal Compiler Error是什麼，你在編譯器研究的過程中遇到的ABI問題，Runtime問題，Linker問題等困難、奇葩的程度或許是做應用程序時都不會遇到的，而這個磨練的過程我覺得就是長功夫的過程。

於是回過頭來看，研究C++編譯器的確會帶來很多對C++不同的認識，會有感覺原來這個是這麼實現的啊，真是漲知識的感覺。然而就對單純的提高C++能力來說，付出和收穫是遠不成正比的，不如去寫STL提升的更快。

利益相關：

IBM XL C++編譯器開發工程師

僅代表個人看法。

我建議題主問自己一個問題：

學習某程序語言的目的是什麼？

是希望學習一個解決問題的工具嗎？

還是為了成為該語言的語法大師，對它的各種正確錯誤用法如數家珍？

還是希望去做該語言的編譯器？

838 頁 C++ primer。

297 頁 effective C++。

看完了再繼續研究編譯器，XX模板庫，」modern元編程「。

每一個都是上千頁的閱讀量。

看似學會了很多。

可是可能到頭來發現：

機器學習不會，

服務端編程從來沒有真正嘗試實現過，

想寫的遊戲一直沒有動手寫，

渲染的數學基本知識沒看過，

圖像處理的演算法不了解，

利用高等數學矩陣來解決優化問題的建模和編程能力沒有，

學習快速構建 app 模型的計劃擱置得已經忘記了。

一個人應該明白自己追求的是什麼。

當然，其實立志成為 Scott Meyers 一樣的 C++ 培訓師其實也不錯。

有些語言的培訓幾乎不賺錢，一上午就結束了。

然而 C++ 的培訓一直是業內培訓最賺錢的，課時多，每隔幾年還都有新的內容上。

作為一個高要求的 C++ 程序員, 稍微了解一下各個編譯器的差異, 一些特性的實現是有一定的好處的. 但個人覺得除非出 core 定位問題以及親朋好友來裝逼, 這樣的好處體現不太明顯.

研究編譯器並不是必需的。

但是，要寫好C++，一定要對**語義**非常清楚。對於一些難懂的內容，可以通過查看標準文件、編譯器源碼或者自己實現等手段來了解。

其實個人體會是，自己動手實現一些STL/Boost庫對學C++幫助更大。

喜歡吃雞蛋的人學好怎麼做雞蛋就好了。

只要當他想吃hen的時候，才有必要去學習怎麼做好一隻hen。

So，如果你打算將來做編譯器開發，當然可以研究一下，否則就沒必要了。