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的一个重要原因。