一．《Google C++ 程式設計風格指南》裡的觀點
公司在推行編碼規範，領導提議基本上使用《Google C++ 程式設計風格指南》。其中《Google C++ 程式設計風格指南》對於標頭檔案的包含順序是這樣的：
Names and Order of Includes
link ▽Use standard order for readability and to avoid hidden dependencies:C library, C++ library, other libraries’ .h, your project’s .h.
All of a project’s header files should belisted as descendants of the project’s source directory without use of UNIXdirectory shortcuts . (the current directory) or .. (the parent directory). Forexample, google-awesome-project/src/base/logging.h should be included as
#include “base/logging.h”
In dir/foo.cc or dir/foo_test.cc, whosemain purpose is to implement or test the stuff in dir2/foo2.h, order yourincludes as follows:
dir2/foo2.h (preferred location — seedetails below).
C system files.
C++ system files.
Other libraries’ .h files.
Your project’s .h files.
The preferred ordering reduces hiddendependencies. We want every header file to be compilable on its own. Theeasiest way to achieve this is to make sure that every one of them is the first.h file #included in some .cc.
dir/foo.cc and dir2/foo2.h are often in thesame directory (e.g. base/basictypes_test.cc and base/basictypes.h), but can bein different directories too.
Within each section it is nice to order theincludes alphabetically.
For example, the includes ingoogle-awesome-project/src/foo/internal/fooserver.cc might look like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
#include "foo/public/fooserver.h" // Preferred location. #include <sys/types.h> #include <unistd.h> #include <hash_map> #include <vector> #include "base/basictypes.h" #include"base/commandlineflags.h" #include "foo/public/bar.h" |
在這裡我談一下我對上面的理解（如不當，還請諸位同學指正）：
1. 為了加強可讀性和避免隱含依賴，應使用下面的順序：C標準庫、C++標準庫、其它庫的標頭檔案、你自己工程的標頭檔案。不過這裡最先包含的是首選的標頭檔案，即例如a.cpp檔案中應該優先包含a.h。首選的標頭檔案是為了減少隱藏依賴，同時確保標頭檔案和實現檔案是匹配的。具體的例子是：假如你有一個cc檔案（linux平臺的cpp檔案字尾為cc）是google-awesome-project/src/foo/internal/fooserver.cc，那麼它所包含的標頭檔案的順序如下：
|
1 2 3 4 5 6 7 8 9 |
#include <sys/types.h> #include <unistd.h> #include <hash_map> #include <vector> #include "base/basictypes.h" #include "base/commandlineflags.h" #include "foo/public/bar.h" |
2. 在包含標頭檔案時應該加上標頭檔案所在工程的資料夾名，即假如你有這樣一個工程base，裡面有一個logging.h，那麼外部包含這個標頭檔案應該這樣寫：
#include “base/logging.h”，而不是#include “logging.h”
我們看到的是這裡《Google C++ 程式設計風格指南》倡導的原則背後隱藏的目的是：
1. 為了減少隱藏依賴，同時標頭檔案和其實現檔案匹配，應該先包含其首選項（即其對應的標頭檔案）。
2. 除了首選項外，遵循的是從一般到特殊的原則。不過我覺得《Google C++ 程式設計風格指南》的順序：C標準庫、C++標準庫、其它庫的標頭檔案、你自己工程的標頭檔案中漏了最前面的一項：作業系統級別的標頭檔案，比如上面的例子sys/types.h估計不能歸入C標準庫，而是Linux作業系統提供的SDK吧。因此我覺得更準確的說法應該是：OS SDK .h , C標準庫、C++標準庫、其它庫的標頭檔案、你自己工程的標頭檔案。
3.之所以要將標頭檔案所在的工程目錄列出，作用應該是名稱空間是一樣的，就是為了區分不小心造成的檔案重名。
二．《C++程式設計思想》中的不同觀點
與《Google C++ 程式設計風格指南》不同的是，《C++程式設計思想》倡導一種不同的規則。《C++程式設計思想》P432提到：
標頭檔案被包含的順序是從“最特殊到最一般”。這就是，在本地目錄的任何標頭檔案首先被包含。然後是我們自己的所有“工具”標頭檔案，隨後是第三方庫標頭檔案，接著是標準C++庫標頭檔案和C庫標頭檔案。
要了解其原因：可以看JohnLakos在《Large ScaleC++ Softwre Design》(注：其中文譯名為《大規模C++程式設計》)中的一段話：
保證.h檔案的組成部分不被它自身解析（parse）,這可以避免潛在的使用錯誤。因為被自身解析缺乏明確提供的宣告或定義。在.c檔案的第一行包含.h 檔案能確保所有對於構件的物理介面重要的內部資訊塊都在.h中（如果的確是缺少了某些資訊塊，一旦編譯這個.c檔案時就可以發現這個問題）。
如果包含標頭檔案的順序是“從最特殊到最一般”，如果我們的標頭檔案不被它自己解析。我們將馬上找到它，防止麻煩事情發生。
三．我的試驗
到底哪一種包含順序好呢？我使用VS 2005編一個控制檯測試工程TestInc，裡面有幾個檔案。
MyMath.h的程式碼如下：
|
1 2 |
#pragma once double acos(double Num); |
MyMath.cpp的程式碼如下：
|
1 2 3 4 |
double acos(double Num) { return 1.0; } |
TestInc.cpp的程式碼如下：
|
1 2 3 4 5 6 7 8 9 10 |
#include "TestInc.h" #include <stdio.h> #include <math.h> int _tmain(int argc, _TCHAR* argv[]) { double a = acos(0.5); return 0; } |
結果出現錯誤：
1>c:program filesmicrosoft visualstudio 8vcincludemath.h(107) : error C2732: 連結規範與“acos”的早期規範衝突
1> c:program filesmicrosoft visual studio 8vcincludemath.h(107) : 參見“acos”的宣告
然後我把TestInc.cpp的標頭檔案包含順序改為：
|
1 2 3 |
#include <stdio.h> #include <math.h> #include "TestInc.h" |
則編譯通過了。在除錯執行時main函式呼叫還是C標準庫的函式acos，看來函式呼叫的順序是按標頭檔案的包含順序來的，即我自定義的acos函式被覆蓋了(如果TestInc.h裡包含了行內函數，則優先呼叫的是行內函數)。
從這個小實驗中我得出如下結論：《Google C++ 程式設計風格指南》和《C++程式設計思想》倡導的包含標頭檔案的順序各有優點，《Google C++ 程式設計風格指南》應該能大量減少隱藏的標頭檔案依賴，而《C++程式設計思想》則很容易讓你清楚知道你所定義的介面是否和系統庫及第三方庫發生衝突。
四．標頭檔案包含中的預編譯功能
在Visual Studio環境下開發我們發現幾乎每個cpp檔案都要包含stdafx.h這個檔案，而且要把它放在最前面的位置，否則就會出錯。這是為什麼呢？
原來Visual Studio採用一種預編譯的機制。要了解預編譯機制，先介紹一下預編譯頭。所謂的預編譯頭就是把一個工程中的那一部分程式碼，預先編譯好放在一個檔案裡（通常是以.pch為副檔名的），這個檔案就稱為預編譯標頭檔案這些預先編譯好的程式碼可以是任何的C/C++程式碼，甚至是inline的函式，但是必須是穩定的，在工程開發的過程中不會被經常改變。如果這些程式碼被修改，則需要重新編譯生成預編譯標頭檔案。注意生成預編譯標頭檔案是很耗時間的。同時你得注意預編譯標頭檔案通常很大，通常有6- 7M大。注意及時清理那些沒有用的預編譯標頭檔案。
也許你會問：現在的編譯器都有Time stamp的功能，編譯器在編譯整個工程的時候，它只會編譯那些經過修改的檔案，而不會去編譯那些從上次編譯過，到現在沒有被修改過的檔案。那麼為什麼還要預編譯標頭檔案呢？答案在這裡，我們知道編譯器是以檔案為單位編譯的，一個檔案經過修改後，會重新編譯整個檔案，當然在這個檔案裡包含的所有標頭檔案中的東西（.eg Macro, Preprocessor ）都要重新處理一遍。 VC的預編譯標頭檔案儲存的正是這部分資訊。以避免每次都要重新處理這些標頭檔案。
根據上文介紹，預編譯標頭檔案的作用當然就是提高便宜速度了，有了它你沒有必要每次都編譯那些不需要經常改變的程式碼。編譯效能當然就提高了。
要使用預編譯頭，我們必須指定一個標頭檔案，這個標頭檔案包含我們不會經常改變的程式碼和其他的標頭檔案，然後我們用這個標頭檔案來生成一個預編譯標頭檔案（.pch 檔案）想必大家都知道StdAfx.h這個檔案。很多人都認為這是VC提供的一個“系統級別”的，編譯器帶的一個標頭檔案。其實不是的，這個檔案可以是任何名字的。我們來考察一個典型的由AppWizard生成的MFC Dialog Based 程式的預編譯標頭檔案。（因為AppWizard會為我們指定好如何使用預編譯標頭檔案，預設的是StdAfx.h，這是VC起的名字）。我們會發現這個標頭檔案裡包含了以下的標頭檔案：
|
1 2 3 4 |
#include <afxext.h> // MFC extensions #include <afxdisp.h> // MFC Automation classes #include <afxdtctl.h> // MFC support for Internet Explorer 4 Common Controls #include <afxcmn.h> |
這些正是使用MFC的必須包含的標頭檔案，當然我們不太可能在我們的工程中修改這些標頭檔案的，所以說他們是穩定的。
那麼我們如何指定它來生成預編譯標頭檔案。我們知道一個標頭檔案是不能編譯的。所以我們還需要一個cpp檔案來生成.pch 檔案。這個檔案預設的就是StdAfx.cpp。在這個檔案裡只有一句程式碼就是：#include“Stdafx.h”。原因是理所當然的，我們僅僅是要它能夠編譯而已―――也就是說，要的只是它的.cpp的副檔名。我們可以用/Yc編譯開關來指定StdAfx.cpp來生成一個.pch檔案，通過/Fp 編譯開關來指定生成的pch檔案的名字。開啟project ->Setting->C/C++ 對話方塊。把Category指向Precompiled Header。在左邊的樹形檢視裡選擇整個工程，Project Options(右下角的那個白的地方)可以看到 /Fp “debug/PCH.pch”，這就是指定生成的.pch檔案的名字，預設的通常是 .pch。然後，在左邊的樹形檢視裡選擇 StdAfx.cpp，這時原來的Project Option變成了 Source File Option（原來是工程，現在是一個檔案，當然變了）。在這裡我們可以看到 /Yc開關，/Yc的作用就是指定這個檔案來建立一個Pch檔案。/Yc後面的檔名是那個包含了穩定程式碼的標頭檔案，一個工程裡只能有一個檔案的可以有 YC開關。VC就根據這個選項把 StdAfx.cpp編譯成一個Obj檔案和一個PCH檔案。
這樣，我們就設定好了預編譯標頭檔案。也就是說，我們可以使用預編譯頭功能了。以下是注意事項：
1）如果使用了/Yu，就是說使用了預編譯，我們在每個.cpp檔案的最開頭，包含你指定產生pch檔案的.h檔案（預設是stdafx.h）不然就會有問題。如果你沒有包含這個檔案，就告訴你Unexpected file end.
2）如果你把pch檔案不小心丟了，根據以上的分析，你只要讓編譯器生成一個pch檔案就可以了。也就是說把stdafx.cpp（即指定/Yc的那個cpp檔案）重新編譯一遍就可以了。
那麼在Linux平臺下有沒有這種預編譯機制呢？如果有，它是怎麼實現的呢？Linux平臺下GCC編譯器也實現了預編譯機制的。這裡以開源IDE CodeBlocks（CodeBlocks內建了GCC編譯器）的工程為例來說明Linux平臺的實現：
使用CodeBlocks建一個C++工程，然後新建一個my_pch.h，輸入如下程式碼：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
/*************************************************************** * Name: my_pch.h * Purpose: Header to create Pre-Compiled Header (PCH) * Author: () * Created: 2010-10-26 * Copyright: () * License: * 使用方法: 專案構建選項-->其他選項-->填入下面兩行 -Winvalid-pch -include my_pch.h **************************************************************/ #ifndef MY_PCH_H_INCLUDED #define MY_PCH_H_INCLUDED // put here all your rarely-changing header files #include <iostream> #include <string> #endif |
然後在專案構建選項–>其他選項–>填入下面兩行
|
1 2 |
-Winvalid-pch -include my_pch.h |
就可以啟用預編譯檔案頭。
然後 main.cpp 就可以不用 include 標頭檔案了，直接這樣就可以編譯了
|
1 2 3 4 5 6 |
int main() { using namespace std; cout << "Hello world!" << endl; return 0; } |
即使在上面的程式碼寫上下面一行，其實是不起作用的：
|
1 |
#include <iostream> |
參考文獻：
1. 編譯器處理相關
http://blog.donews.com/xzwenlan/archive/2004/12/23/211668.aspx
2. GoogleC++ Style Guide
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Names_and_Order_of_Includes
3.《C++程式設計思想》
4. VC++的預編譯功能
http://www.neu.edu.cn/cxsj/pointchart/c11/VC++%282%29.html