GCC 用 C++ 來編譯

GCC在2012年8月15日的時候，merge了一個patch - Merge from cxx-conversion branch，這意味著，以後在GCC的編譯只能用C++的編譯器了，也意味著，gcc的實現代碼開始轉向C++了。

你可能會有兩個問題，

• 一個問題是為什麼GCC要轉成C++的實現？
• 沒有C++的編譯器，我怎麼編譯C++編譯器的代碼？這不是“雞生蛋還是蛋生雞”的問題麼？

那，我們來看一看吧。

為什麼要用C++

在GNU的C++ Conversion文檔中，我們可以在Background中看到這樣的描述：

Whether we use C or C++, we need to try to ensure that interfaces are easy to understand, that the code is reasonably modular, that the internal documentation corresponds to the code, that it is possible for new developers to write new passes and to fix bugs. Those are the important issues for us to consider. The C++ features which are not present in C – features which are well documented in many books and many web sites – are not an important issue.

這句話的意思可以理解為，今天GCC在用C語言的實現已經有點hold不住了，因為，開發人員覺得，不管我們用C或C++，都需要努力確保接口是容易理解的，這樣我們的代碼是想當理性地被模塊化的，這樣內部文檔和代碼一致，這樣可以更好地組織代碼，這樣有利於新人了fix-bug。而C++正好可以讓他們更好的完成這些東西。

GNU還給出了下面這些理由：

• C++ 是一種標准化的，大眾的，流行的語言。
• C++ 是C90的超集。
• C++作為C的擴展和C在性能上一樣好。
• C++ 在一些有意義的案例上支持更干淨的代碼。
• C++ 讓你更容易去寫一個更干淨的接口。
• C++ 永遠不會讓你的代碼變得更丑。
• C++ 不是萬靈藥，他是C的一個改進。

然後，給了一個PDF http://airs.com/ian/cxx-slides.pdf，這是Google 的 Ian Lance Taylor的的一個PPT，這個文檔可以讓大家更好地理解我在《C++的坑多嗎？》一文中那些觀點。我都不知道我要說多少遍C++的封裝，繼承和多態比C語言在代碼組織上要好得多得多。大家還是自己看一下代碼吧：

數據結構的操作 —— 你寫的一定不會有STL好

結構套結構還是繼承？

函數指針還是多態？

垃圾回收 還是 智能指針？

Why not C++? 

• C++慢嗎？某些特性會慢，但是有時C++更快，你可以只用你喜歡的C++特性。
• C++復雜嗎？它只不過是另一種編程語言，他可以讓你對程序員維護更簡單。
• FSF不喜歡C++！因為FSF自由軟件基金會）這些人不寫代碼。

Bootstrapping

最後，我想來介紹一下Bootstrapping。 所謂Bootstrapping，就是用自己這個語言寫編譯器來編譯自己，也就是說如果你要編譯gcc，你需要用一個c的編譯器來編譯之，這個就是bootstrapped process，自舉過程。包括 BASIC, Algol, C, C++, Pascal, PL/I, Factor, Haskell, Modula-2, Oberon, OCaml,Common Lisp, Scheme, Java, Python, Scala 等語言都這麼干。

這樣干的好處主要是，自己可以測試自己，編譯器的改善和語言的改善相輔相成。

但是，這是一個“雞生蛋，還是蛋生雞”的問題，如果你需要用X語言來寫一個X語言編譯器的語言，你可以這樣干：

• 用Y語言來實現X的語言解釋器或編譯器。 Niklaus Wirth 說 Pascal 的第一個編譯器是由 Fortran 寫的。
• 已存在用Y語言寫的X語言的編譯器或解釋器。Scheme 就是這麼干的。
• 已經有一個編譯器來編譯一個早期版本的X語言，然後就可以用早期版本的X語言來編譯新版本的X語言了。Java，Haskell, 和最初版的 Free Pascal 就是這麼干的。
• X在某平台上的編譯器已經存在，可以使用交叉編譯技術來編譯另一個平台上X語言，C語言就是這麼干的。
• 用X語言寫一個編譯器，然後手動編譯之不需要特別優化），注：手動編譯估計就是手動翻譯成機器匯編代碼），然後再運行這個手動編譯的編譯器來編譯這個編譯器的源碼，並優化之。Donald Knuth 在他的 WEB literate programming 系統裡用到了這個方法。