淺談GCC預編譯頭技術

文/jorge

——謹以此文，悼念我等待MinGW編譯時逝去的那些時間。

其 實剛開始編程的時候，我是絲毫不重視編譯速度之類的問題的，原因很簡單，因為那時我用BASICA。后來一直用到C++ Builder，盡管Borland的廣告無時無刻不在吹噓其編譯速度，我卻從沒有對這個問題上心過，因為心里根本沒有“編譯速度慢”這種概念。沒有壞，哪來好？所謂矛盾的對立統一。遇到的第一個“慢”的編譯器也許是javac，但因為Java的特殊性，也就容忍了。真正接觸到世間的“惡勢力”，還要算是第一次使用GCC的時候……準確地說是MinGW。開源世界曾給我諸多驚喜，其一就是原來編譯器也可以這么慢的。那時我不禁對開源社區肅然起敬，他們就用這樣的編譯器，建立起了怎樣一個多彩的世界！也在那時才明白了，Borland其實真的很了不起。

時至今日我也不是很了解Borland是怎么做到的，很久以來也不知道GCC是差在了哪里。然而……有一次心血來潮，忽然想看看 MinGW編譯過程中加載的所有頭文件。于是用了一下 -H 參數。結果是滿意的，加載的頭文件真多呀。接下來……開始感覺到另外的一些東西了。敢情，大部分編譯時間是浪費在這里的呀？——“預編譯頭”的概念如鯨魚般躍出腦海。

預編譯頭技術是在VC中第一次了解的，其對編譯速度的提高，絕對給人以深刻的印象。使用MinGW的時候居然忘了這個古老的咒語。是否正是我所需要的？百度幾下，結果令人失望，這方面的文獻少得可憐，更令人沮喪的是還有不少人相信GCC是沒有預編譯頭技術的。賊心不死的我打開 GCC官方文檔，查找precompiled headers。慢著，居然如此順利！——官方文檔討論篇幅并不長，但足以讓我喊萬歲了~不用多，一句話就夠了，怎么說來著？Simply compile it!

所謂預編譯頭，就是把頭文件事先編譯成一種二進制的中間格式，供后續的編譯過程使用。不要把這個中間格式與. o/.obj/.a/.lib的格式混淆，他們是截然不同的，所以預編譯頭文件的特性和目標文件也不同（盡管他們都屬于某種中間文件）。——但也有類似的地方的，比如，它們都是編譯器之間不兼容的^_^，就是說你不能把VC生成的預編譯頭拿到GCC上去用。甚至擴展名都不一樣，VC的是大家都熟悉的. pch，而GCC的，是.gch——今天的主角。

為什么要使用預編譯頭？再明確不過了，提高編譯速度。為什么會提高編譯速度？這么說吧，你有兩個文件a.cpp和b.cpp，都包含了同一個頭文件c.h。那么正常的流程是：將c.h和a.cpp合并，編譯成a.o；將c.h和b.cpp合并，編譯成b.o；最后將a.o和b.o鏈接成可執行文件。過程很簡單，浪費時間之處也一目了然：頭文件c.h的內容實際上被解析了兩遍。也許你要說，當然要兩遍了，因為頭文件幾乎是不生成任何代碼的，只有依附于具體的.cpp文件才有意義。正確，但那只是在代碼執行過程中。但在代碼編譯的時候呢？編譯器讀入源代碼，首先將其解析成為一種內部的表示方式。這個過程與其所依附的.cpp文件并無關系，編譯器接著可以讀入.cpp文件并同樣解析成內部表示，然后把兩段內部表示拼接起來，再進行接下來的操作。既然編譯兩個.cpp文件都要先對c.h進行解析，那干嘛不把c.h解析好了保存成臨時文件，用時讀入，不就可以省了一次解析的時間了嗎？——預編譯頭技術節省時間的原理正在于此，尤其是在這樣一個事實下：對源代碼的“解析”這個步驟，確實是占了編譯時間中很可觀的一部分。

我看見你滿是狐疑的臉：預處理，就是編譯之前的處理，合并.h和.cpp文件分明是預處理的步驟，而解析源代碼是編譯之中的步驟，先解析后合并？怎么“預”處理反而跑到編譯步驟之后了？這還叫“預”嗎？——這個問題我們決定不深究了，畢竟現在的編譯器早就混淆了預處理與編譯的界限……畢竟，這么做是管用的，對嗎？

我們來看看結果。寫一個C++的Hello world，使用cout輸出一行字。包含了什么頭文件？當然是iostream。這個頭文件對于人們來說，絕對是熟視無睹級別的。然而使用它的時候，你注意到編譯器幕后的累累“罪行”了嗎？是的，用 -H 參數編譯一下這個Hello world吧！看看總共加載了多少個頭文件？我的機器上，總共103個！

是的，你應該將它們做成一個.gch文件。如何做？如前所述，再簡單不過：只要編譯它就可以了：

g++ xxx.h

一句話，就是：把.h文件當成.cpp文件一樣來編譯。這是最簡單的，如果需要控制編譯細節，比如常量定義之類，大可加上其它選項。運行之后，你會發現同個目錄里生成了一個名叫xxx.h.gch的文件，這就是我們要的。也許你和我一樣，迫不及待地嘗試g++ iostream了？呵呵，結果一定是和我一樣的失敗——在編譯.gch的過程中，GCC并沒有使用環境變量或 -I 選項來查找被編譯的頭文件，被編譯的頭文件必須在當前目錄下。然而，被編譯的頭文件所進一步包含的其它頭文件，卻可以通過以上途徑找到。簡言之，就是把直接編譯的那個頭文件以類似對待.cpp文件的方式處理了。現在知道該如何編譯iostream了吧？對，在當前目錄里建立一個頭文件，起個隨你喜歡的名字，比如foo.h，在其里面寫上：#include <iostream>，然后編譯它：g++ foo.h。生成的foo.h.gch，就是我們要的了。其它文件需要用到iostream的，不要包含iostream，要包含foo.h。切記，不是去包含foo.h.gch！

如果你用過VC，那么這個foo.h也許會讓你找到一種似曾相識的感覺吧？對了，就相當于那個 stdafx.h！那么你也該記得，每個文件包含這個foo.h，都應該在文件一開始的地方，否則會出錯。真的，終于找到了GCC中的stdafx.h，這種感覺幾乎讓人熱淚盈眶了^_^

那么接下來，照搬一些stdafx.h相關的注意事項吧，它們同樣適用于.gch文件：應該把那些不常修改的（首當其沖，當然是系統的）頭文件放在預編譯頭里，而那些屬于你的程序的一部分的頭文件，一般并不放在預編譯頭里，因為它們可能隨時要被修改的。每修改一次就要重新生成預編譯頭，并沒有速度優勢可言，失去預編譯頭的意義了。另外重要的注意事項是：如果你生成預編譯頭的時候用了一些選項，比如宏定義，那么使用這個預編譯頭的其它源代碼文件，被編譯的時候也要使用這些選項，否則會因為不匹配而編譯失敗。

對了，說了半天，從來沒有正面講過如何使用已經生成的預編譯頭。然而看到這里也該明白了，是的，很簡單，只要包含其所對應的.h文件即可！比如你有個頭文件叫foo.h，另外有一大堆其它文件都包含了這個foo.h，原來沒有使用預編譯頭技術，現在忽然想使用了，于是把foo.h編譯成了foo.h.gch。那其它文件要做怎樣的修改？——什么都不用，一切照舊！聰明的GCC編譯器在查找一個.h文件之前，會自動查找其目錄里有沒有對應的.gch文件，如有，且可用，則用之；沒有，才用到真正的.h頭文件。——慢著，“如有，且可用”，什么叫“可用”？——就是指這個.gch格式要正確，版本要兼容，而且如上所述，編譯兩者要用同樣的選項。如果.gch不可用，編譯器會給出一條警告，告訴我們：這個預編譯頭不能用！我只好用原有的.h 頭文件啦！什么？你說看不到這個警告？——當然，要先打開 -Winvalid-pch 選項才行，其默認是關閉的。

用 -H 選項感受一下預編譯頭的清爽吧！再沒有滾不完的頭文件了，明顯提高的速度，絕對會讓你有種翻身解放的感覺，原來MinGW也可以和蝸牛般的速度說再見的。

總結

以上是生活随笔為你收集整理的浅谈GCC预编译头技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。