（转）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的一个重要缘由。