（轉）Clang 比 GCC 編譯器好在哪裏？

編譯速度更快、編譯產出更小、出錯提示更友好。尤爲是在比較極端的狀況下。

兩年多前曾經寫過一個Scheme解釋器，詞法分析和語法解析部分大約2000行，用的是Boost.Spirit——一個重度依賴C++模版元編程的框架。當時用g++ 4.2編譯的狀況是：

1. 編譯速度極慢：完整編譯一次須要20分鐘
   
2. 編譯過程當中內存消耗極大：單個g++實例內存峯值消耗超過1G
3. 中間產出物極大：編譯出的全部.o文件加在一塊兒大約1~2G，debug連接產物超過200M
4. 編譯錯誤極其難以理解：編譯錯誤常常長達幾十K，基本不可讀，最要命的是編譯錯誤常常會長到被g++截斷，看不到真正出錯的位置，基本上只能靠裸看代碼來調試

這裏先不論我使用Spirit的方式是否是有問題，或者Spirit框架自身的問題。我當時由於實在忍受不了g++，轉而嘗試clang。當時用的是clang 2.8，剛剛能夠完整編譯Boost，效果讓我很滿意：

1. 編譯速度有顯著提高，記得大約是g++的1/3或1/4
2. 編譯過程當中的內存消耗差異好像不大
3. 中間產出物及最終連接產物，記得也是g++的1/3或1/4
4. 相較於g++，編譯錯誤可讀性有所飛躍，至少不會出現編譯錯誤過長被截斷的問題了

當時最大的缺點是clang編譯出的可執行文件沒法用gdb調試，須要用調試器的時候還得用g++再編譯一遍。不過這個問題後來解決了，我不知道是clang支持了gdb仍是gdb支持了clang。至少我當前在Ubuntu下用clang 3.0編譯出的二進制文件已經能夠順利用gdb調試了。 最後一點，其餘同窗也有講到，就是Clang採用的是BSD協議。這是蘋果資助LLVM、FreeBSD淘汰GCC換用Clang的一個重要緣由。