包括頭文件樣式 - C ++

Question

我有一個具有以下目錄結構的項目。

root
--include
----module1
----module2
--src
----module1
----module2

所以一個文件說src/module1 foo.cpp中的foo.cpp必須包括像，

#include "../../include/module1/foo.hpp"

這看起來很混亂，很難寫。 我發現寫作包括喜歡

#include <module1/foo.h>

並且在編譯看起來很整潔時提供包含文件搜索路徑到root/include 。 但是，我不確定這種風格有任何缺點。

您更喜歡哪一個？為什么？ 你也看到以上述方式組織文件有什么問題嗎？

Answer 1

#include "../../include/module1/foo.hpp"

應盡可能避免指定路徑。 編譯器為您提供了更清晰的替代方案。 此外，干凈的設計應該確保您不需要處理包含標題的相對路徑。

可以從標准中更好地了解使用哪一個（包括使用引號還是尖括號）。

從我的C ++草案副本：

16.2源文件包含

2表單的預處理指令

#include <h-char-sequence> new-line`

搜索一系列實現定義的位置，以查找由<和>分隔符之間的指定序列唯一標識的標頭，並使標頭的整個內容替換該指令。 如何指定場所或標識的頭是實現定義的。

3表單的預處理指令

# include "q-char-sequence" new-line 

導致由“delimiters”之間的指定序列標識的源文件的全部內容替換該指令。以實現定義的方式搜索指定的源文件。如果不支持此搜索，或者搜索失敗，該指令被重新處理，就像它讀取一樣

#include <h-char-sequence> new-line`

使用原始指令中相同的包含序列（包括>字符，如果有的話）。

7雖然實現可以提供一種機制來使任意源文件可用於<>搜索，但一般來說程序員應該使用<>表單作為實現提供的頭文件，並使用“”表單來實現控制之外的源。

Answer 2

我支持兩種風格......用於不同的用途

我們假設您的示例中還有一個目錄root/src/common

// in src/module1/foo.cpp
#include "module1/foo.h"

#include "../common/stringProcessing.h"

包括

我不喜歡看到'include'目錄，因為當然說找到確切的頭文件更難...但是當你開始並轉向多個獨立庫時你需要抽象，因為你希望能夠在不改變代碼的情況下移動各種組件，我都是為了保持一致性。

此外，使用'..'總是存在風險，因為向后遍歷的符號鏈接，它不會出現在你想到的地方：/

資源

有時您的標頭不是公共的，因此不在include目錄中。 這些通常用於與您的客戶無關的實施細節。 對於那些我使用..如果需要和精確的確切位置。

這允許： - 不要將-I與src所有可能目錄src - 在源代碼中輕松找到文件 - 輕松測試源代碼之間的依賴關系（grep for .. ）

雜項

如果我要打字

#include "module/foo.h"

然后我希望使用：

module::Foo myClass;

這使得將一種特定類型與一個特定模塊匹配變得容易。

要求一個庫 - 一個名稱相同的命名空間，可以很容易地導航我們工作的一些~300或~400個組件：我們需要通過某種方式來組織它們！

這意味着您的初始布局會被重新設計為（對於module項目）：

root
-- include
---- module
------ part1
------ part2
-- src
---- part1
---- part2

然后使用以下指令： -I/path../root/include我希望您創建libmodule.so庫或module二進制文件。

Answer 3

我更喜歡第二種方式

#include <module1/foo.h>

我發現它使源更易於查看。 問題是，當其他人來看你的代碼時，它不一定是頭文件所在的固有位置，而包含的第一種方式是。

Answer 4

每種風格都有一些缺點，但我更喜歡你指定的風格。 包含路徑不得包含任何向上相關性（例如../.. ），並且必須指定它所依賴的模塊。

Answer 5

作為一個小改進，我建議你允許module1中的cc文件直接訪問他們的.h文件：

module1/%.cc: -I $ROOT/includes/module1

或類似的。 這將在您的c文件中創建一個視覺效果，區分外部包含和默認包括：

// module1/abc.cc
#include <abc.h>
#include <module2/def.h>

Answer 6

Google的C ++風格指南中有一節介紹了包含的排序和命名。 它基本上同意到目前為止在其他答案中所說的內容，但值得一看，因為它非常具體。

我更喜歡（和Google同意）在include指令中沒有使用..的相對路徑。 您初步評估它看起來整潔是正確的。 擁有冗長，笨重的相對路徑會使事情更難閱讀，更難以重構。 我認為你的方法是正確的。

至於將源文件和包含文件分成兩個不同的子樹：為什么不將源頭文件放在源文件旁邊？ 它使它們更容易匹配。 除非你希望其他項目使用你的標題，只是鏈接到你的二進制文件，我想。
<聳肩/>

Answer 7

我不在#include指令中使用路徑。 根據我的經驗，它們總是在維護階段引起問題。 許多編譯器允許您為頭文件指定搜索樹。

文件可以移動

他們會的。 您的層次結構將會改變 您可能希望將文件放在不同的驅動器上。 當其他用戶修改您的代碼時，他們可能會更改位置。 當文件移植到另一個項目時，文件可能會移動。 沒有什么能阻止您的文件移動。

在不修改文件的情況下移動文件

知道文件將移動，如果路徑在文件中，則移動文件時必須修改該文件。 如果沒有文件中的路徑，則只需要更改構建指令。 對於大型項目，修改許多文件很麻煩（即使使用腳本）。

在我看來， #include指令中的路徑是邪惡的。 執行此操作的人員應接受再培訓或發送給其他公司。