#include「xxx.h」上的規則是什麼？#sinclude <xxx.h>？

Question

如果我有我自己的圖書館項目，我應該使用哪種風格的#include他們在我的應用程序中的標題？是否有嚴格的規則，並且這兩者實際上對編譯器/預處理器有不同的含義，還是隻針對標準？

Answer 1

通常，使用引號表示頭文件位於項目目錄的相對位置。另一方面，如果使用尖括號，編譯器會期望您的頭文件位置爲標準位置。例如/usr/include,/usr/local/include或您的編譯器的任何其他默認位置。

在GCC如果您使用-I標誌，包括與角括號將在指定的位置搜索也。

例子：

$ gcc -Wall -I/path/to/my/library/include myfile.c 

所以，如果你在/path/to/my/library/include有myfile.h，您可以在myfile.c源使用#include <myfile.h>。

Answer 2

根據ISO標準，有幾條規則。這兩種形式都依賴於實現，因爲它們在哪裏查找頭文件。他們甚至不必爲文件。

科C++ 11 2.9使得比其他事實，兩個品種之間沒有區別，你可以包括在<>變種"和>在""變量，但很少人會傻得使用文件名中這些字符:-)

科16.2進一步指出：

---

形式# include < h-char-sequence> new-line搜索的預處理指令由指定序列唯一標識的標題的實現定義位置序列，該位置由<和>定界符之間的指定序列唯一標識，並導致該標題的全部內容替換該指令。如何指定位置或標識的是實現定義的。

形式爲# include " q-char-sequence" new-line的預處理指令導致用指定序列標識的源文件的全部內容替代該指令，該源文件由"定界符之間的指定序列標識。指定的源文件是以實現定義的方式搜索的。如果此搜索不受支持，或者搜索失敗，則會重新處理該指令，就像它讀取的# include < h-char-sequence> new-line具有相同的包含序列（包括來自原始指令的>個字符，如果有的話）。

---

我傾向於使用我自己的頭<>系統頭和""，但僅是個人喜好。我想指出的是，上述C++ 11號文件規定：

注意：雖然實現可用於製造可用於<>搜索任意源文件，一般的程序員應該使用<>形式提供的頭文件提供了一種機制與實施，以及""形式的實施控制之外的來源。

這不是強制性的，但它仍是一個好主意。

Answer 3

它影響預處理程序搜索包含文件的位置。從MSDN：

「引用形式：此表單指示預處理程序在包含#include語句的文件的相同目錄中查找包含文件，然後在包含（#include）的任何文件的目錄中查找然後預處理器沿着/ I編譯器選項指定的路徑搜索，然後沿INCLUDE環境變量指定的路徑搜索。

角支架形式：此表單指示預處理器首先沿路徑搜索包含文件由/ I編譯器選項指定，然後在從命令行編譯時，沿着由INCLUDE環境變量指定的路徑。「

作爲一個粗略的指南，當我試圖指定一個相對於包含帶有#include的文件的目錄的路徑時，我只使用了引號。否則，我只是使用尖括號。從我目前的項目的例子：

#include <algorithm> // standard library headers 
#include <numeric> 
#include <stack> 

#include <boost/function.hpp> // third-party library headers 
#include <boost/lexical_cast.hpp> 

#include <common/io/util/LineIO.h> // specified relative to my own base include dir 
#include "PartitionForest.h" // a header in the current directory 

Answer 4

有幾個不同的操作系統使用的幾十編譯器之後，我的建議是使用<x.h>只爲系統和頭包括具體的操作，以及"y.h"其他一切，包括你的庫和項目標題。

然後，使用編譯器的-I（或其他）選項設置適當的包含搜索路徑。如果您使用類似make或ant來進行構建，這會更容易。

對於第三方軟件標題，您可以使用任一表單。如果軟件包已安裝且可供所有用戶訪問（例如，在某個地方如/usr/local/bin或/usr/site/bin），那麼<x.h>表單可能更正確。如果它安裝在本地構建樹中，那麼"y.h"表單更加正確，因爲它在構建過程中受到控制。

這種組合是最便攜的。