Mac OS X 10.6即所谓的Snow Leopard操作系统已正式发售。一如既往，Apple产品光鲜的外表下凝聚了太多艰辛的劳作。ArsTechnic的John Siracusa以其独特的、专业的、全面的视角深入翔实地体验这款最新的操作系统。
Weiphone.com将对该综述进行翻译整理并独家连载。欢迎关注。
早在几年以前，Apple就在LLVM开源计划上做出了重要的战略性投资。我曾在一篇介绍Mac OS X Leopard的文章中简要介绍了LLVM的一些基本情况，Leopard利用LLVM技术为JIT编译软件的OpenGL功能提供了高效的执行支持。在 那篇综述的最后，我这样结尾：
随着Snow Leopard的推出，这一切开始逐渐浮出水面：Clang和LLVM已成为Apple现行的编译策略。LLVM甚至还有一个全新的帅气的标：
目前，Apple为Mac OS X总共提供了四种编译器：GCC 4.0，GCC4.2，LLVM-GCC 4.2，以及Clang。这里是一个图表：
所有这些编译器在Mac OS X上均具有二进制兼容性(binary-compatible)，这就意味着您可以使用一种编译器创建一个资源库并与使用另一个编译器创建的可执行文件相 链接。并且，理论上讲，这些都是命令行编辑器并且都具有资源兼容性。然而，Clang目前暂不支持GCC的一些复杂功能，同时Clang只支持C、 Objective-C和一点点C++(而GCC支持的相对较多)。Apple承诺，Clang未来将会为C++提供全方位支持，并且希望能够在Snow Leopard的“服役期间”内解决GCC的不兼容问题。
Apple为Clang带来了两条引人注目的特性，那就是：更短的编译时间和更快的可执行文件。Apple用其自身的软件如iCal，Address Book，Xcode，以及一些第三方软件如Adium和Growl进行了测试，Clang编译器比GCC4.2快了近乎3倍。而对于编译的可执行文件运 行速度，由Clang生成的可执行文件则比GCC 4.2生成的可执行文件快5~25%。
同时，与其前任GCC相比，Clang提供了更为友好的开发环境。我承认这和多核CPU等新技术的优势并无很大关联，但这确实开发者在使用Clang时 首先面对的。
对于新手来说，Clang具有可嵌入性，因此Xcode可以在IDE的一些交互功能中使用和最终的可执行文件相同的编译器结构。在编译过程 中，Clang创建并保留了大量详细的元数据(metadata)，从而有利于调试和错误报告。例如，如果GCC返回如下错误：
这时候很难说清问题究竟在哪，对于编程新手来说尤为如此。好吧，牛人或许已经看出来问题在哪了(如果您在WWDC上看到了这个例子的话)，但是我相信大 家都会认为Clang返回的错误报告更有用：
可能个别菜鸟仍然不知所措，但是至少可以清晰地看到问题究竟出在哪里了：与GCC含糊其辞的回应相比，Clang明明白白告诉你，哥们儿我不认识 “NSString”这个类型…
而且，有时候即使错误信息很明确，具体细节却未必如此，譬如GCC返回的这个错误提示：
很明显，“无效的运算符号+”，但是这条语句中有4个“+”，究竟哪一个有问题呢？多亏这些相近的元数据(metadata)，Clang可以明确地为 您指出问题所在：
更进一步抬杠。有时候错误一目了然，譬如这个GCC的例子，在报错行以上的语句中丢失了一个分号“；”：
而Clang则更进一步，指出了究竟哪里丢失了这个分号：
楼下同学说了，这些都是“小事儿”，完全是鸡蛋里头挑骨头没事儿找事儿，然而对于程序员来说，Clang提供的这种更为细致和细心的提示是相当贴心的。 当然，还有一些细节对于程序员来说则意义重大了，譬如这个基于LLVM的静态分析器(static analyzer)。下图显示了静态分析器发现并指出了一处可能的bug：
图中高亮的部分明确地指出了任何一位程序员都有可能犯的bug。静态分析器检测到，这一系列嵌套条件中，“myName”变量在至少一条路径里中未被初 始化，从而使得在最后一行发送“mutableCopy”时存在潜在的危险。
我相信Apple一定在其所有应用程序和操作系统上运行过静态分析器，以检查一些潜在的bug。而对程序员来说，能够在庞大的代码库中自动监测潜在的 bug，无疑是一件非常爽的事情，对于自己开发平台的程序员来说更是如此。某种程度上来讲，Mac OS X 10.6.0中存在的bug比先前的任何一个10.x.0系统的bug都要少，无疑这将归功于LLVM。
通过Clang/LLVM的进一步推广和完善，Apple终于能够完全掌控其自己的开发平台了。CodeWarrior的经验显然使Apple更加清晰 地认识到，依赖于第三方平台开发工具是相当不明智的。尽管花费了许多年的时间，但我认为即使最顽固的Metrowerks支持者也会认为，Snow Leopard提供的Xcode确实是个相当不错的IDE。
许多年以来Apple一直纠结于GCC计划与Apple自身的编译需求之间的脱节，现在Apple终于痛下决心另辟蹊径。诚然，GCC 4.2仍然是Snow Leopard的默认编译器，但是很显然Apple已进入的过渡期。Clang自然是推荐的编译器，并且在可预见的将来，Apple的焦点将集中于此。
上期连载中已经提到，硬件领域的技术进步已经使得软件和操作系统成为了目前限制计算机性能的主要因素。或许您会有一些疑惑，究竟这些编译器将如何帮助开 发者更好地利用现有的硬件资源呢？下期连载将为您分析这个问题。
Weiphone.com将对该综述进行翻译整理并独家连载。欢迎关注。
引用译注：为了 帮助您更加顺畅地理解本文的内容，这里补充了文中一些相关概念的背景资料。
编译器(compiler)： 是一种能够将源代码(通常由高级别的程序语言编写而成)转换为低级别机器语言的程序。源码转换最重要的一个目的在于创建可执行文件。 详情请参考 wikipedia。
LLVM(Low Level Virtual Machine，低级虚拟机)：是构架编译器(compiler)的框架系统，以C++编写而成，用于优化以任意程序语言编写的程序的编 译时间(compile-time)、链接时间(link-time)、运行时间(run-time)以及空闲时间(idle-time)，对开发者保持 开放，并兼容已有脚本。LLVM计划启动于2000年，最初由University of Illinois at Urbana-Champaign的Chris Lattner主持开展。2006年Chris Lattner加盟Apple Inc.并致力于LLVM在Apple开发体系中的应用。Apple也是LLVM计划的主要资助者。 详情请参考llvm.org以及 wikipedia。
GCC(GNU Compiler Collection，缩写为GCC)：是GNU计划推出的支持多种程序语 言的编译器系统。GCC是GNU Toolchain的主要组件。同时作为GNU操作系统的官方编译器，GCC已被作为很多现代操作系统的标准编译器，如GNU/Linux，BSD以及 Mac OS X；同时也可用于很多嵌入式平台，如Symbian，AMCC等；还可用于一些游戏机平台如Playstation和Sega Dreamcast等。 详情请参阅Wikipedia以及 GCC.GNU.org。
IDE(Integrated development environment)：是一种能够为程序员和软件开发提供广泛支持的软件程序。IDE通常由源码编辑器、编 译器、自动化构建工具以及调试器组成。 详情请参阅Wikipedia。
早在几年以前，Apple就在LLVM开源计划上做出了重要的战略性投资。我曾在一篇介绍Mac OS X Leopard的文章中简要介绍了LLVM的一些基本情况，Leopard利用LLVM技术为JIT编译软件的OpenGL功能提供了高效的执行支持。在 那篇综述的最后，我这样结尾：
引 用对于LLVM，Apple拥有相当宏伟的计划：逐步摒弃Mac OS X中现有的GCC编译器集合(complier collection)，并采用全新的基于LLVM的编译器系统。该计划称为"Clang"，并且已有了一些可喜的进展。
随着Snow Leopard的推出，这一切开始逐渐浮出水面：Clang和LLVM已成为Apple现行的编译策略。LLVM甚至还有一个全新的帅气的标：
目前，Apple为Mac OS X总共提供了四种编译器：GCC 4.0，GCC4.2，LLVM-GCC 4.2，以及Clang。这里是一个图表：
所有这些编译器在Mac OS X上均具有二进制兼容性(binary-compatible)，这就意味着您可以使用一种编译器创建一个资源库并与使用另一个编译器创建的可执行文件相 链接。并且，理论上讲，这些都是命令行编辑器并且都具有资源兼容性。然而，Clang目前暂不支持GCC的一些复杂功能，同时Clang只支持C、 Objective-C和一点点C++(而GCC支持的相对较多)。Apple承诺，Clang未来将会为C++提供全方位支持，并且希望能够在Snow Leopard的“服役期间”内解决GCC的不兼容问题。
Apple为Clang带来了两条引人注目的特性，那就是：更短的编译时间和更快的可执行文件。Apple用其自身的软件如iCal，Address Book，Xcode，以及一些第三方软件如Adium和Growl进行了测试，Clang编译器比GCC4.2快了近乎3倍。而对于编译的可执行文件运 行速度，由Clang生成的可执行文件则比GCC 4.2生成的可执行文件快5~25%。
同时，与其前任GCC相比，Clang提供了更为友好的开发环境。我承认这和多核CPU等新技术的优势并无很大关联，但这确实开发者在使用Clang时 首先面对的。
对于新手来说，Clang具有可嵌入性，因此Xcode可以在IDE的一些交互功能中使用和最终的可执行文件相同的编译器结构。在编译过程 中，Clang创建并保留了大量详细的元数据(metadata)，从而有利于调试和错误报告。例如，如果GCC返回如下错误：
这时候很难说清问题究竟在哪，对于编程新手来说尤为如此。好吧，牛人或许已经看出来问题在哪了(如果您在WWDC上看到了这个例子的话)，但是我相信大 家都会认为Clang返回的错误报告更有用：
可能个别菜鸟仍然不知所措，但是至少可以清晰地看到问题究竟出在哪里了：与GCC含糊其辞的回应相比，Clang明明白白告诉你，哥们儿我不认识 “NSString”这个类型…
而且，有时候即使错误信息很明确，具体细节却未必如此，譬如GCC返回的这个错误提示：
很明显，“无效的运算符号+”，但是这条语句中有4个“+”，究竟哪一个有问题呢？多亏这些相近的元数据(metadata)，Clang可以明确地为 您指出问题所在：
更进一步抬杠。有时候错误一目了然，譬如这个GCC的例子，在报错行以上的语句中丢失了一个分号“；”：
而Clang则更进一步，指出了究竟哪里丢失了这个分号：
楼下同学说了，这些都是“小事儿”，完全是鸡蛋里头挑骨头没事儿找事儿，然而对于程序员来说，Clang提供的这种更为细致和细心的提示是相当贴心的。 当然，还有一些细节对于程序员来说则意义重大了，譬如这个基于LLVM的静态分析器(static analyzer)。下图显示了静态分析器发现并指出了一处可能的bug：
图中高亮的部分明确地指出了任何一位程序员都有可能犯的bug。静态分析器检测到，这一系列嵌套条件中，“myName”变量在至少一条路径里中未被初 始化，从而使得在最后一行发送“mutableCopy”时存在潜在的危险。
我相信Apple一定在其所有应用程序和操作系统上运行过静态分析器，以检查一些潜在的bug。而对程序员来说，能够在庞大的代码库中自动监测潜在的 bug，无疑是一件非常爽的事情，对于自己开发平台的程序员来说更是如此。某种程度上来讲，Mac OS X 10.6.0中存在的bug比先前的任何一个10.x.0系统的bug都要少，无疑这将归功于LLVM。
通过Clang/LLVM的进一步推广和完善，Apple终于能够完全掌控其自己的开发平台了。CodeWarrior的经验显然使Apple更加清晰 地认识到，依赖于第三方平台开发工具是相当不明智的。尽管花费了许多年的时间，但我认为即使最顽固的Metrowerks支持者也会认为，Snow Leopard提供的Xcode确实是个相当不错的IDE。
许多年以来Apple一直纠结于GCC计划与Apple自身的编译需求之间的脱节，现在Apple终于痛下决心另辟蹊径。诚然，GCC 4.2仍然是Snow Leopard的默认编译器，但是很显然Apple已进入的过渡期。Clang自然是推荐的编译器，并且在可预见的将来，Apple的焦点将集中于此。
上期连载中已经提到，硬件领域的技术进步已经使得软件和操作系统成为了目前限制计算机性能的主要因素。或许您会有一些疑惑，究竟这些编译器将如何帮助开 发者更好地利用现有的硬件资源呢？下期连载将为您分析这个问题。
来源：oschina
链接：https://my.oschina.net/u/254222/blog/96697