Snow Leopard 充滿活力的心臟 —— LLVM 和 Clang @ 網絡資訊誌C

Mac OS X 10.6即所謂的Snow Leopard操作系統已正式發售。一如既往，Apple產品光鮮的外表下凝聚了太多艱辛的勞作。 ArsTechnic的John Siracusa以其獨特的、專業的、全面的視角深入翔實地體驗這款最新的操作系統。

引用

譯註：為了幫助您更加順暢地理解本文的內容，這裡補充了文中一些相關概念的背景資料。

編譯器(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：