在我的項目中，我目前使用相對路徑來包含我的文件，但這些文件並不經常更改。但是，它會產生很奇怪的包含模式，因爲我通常將我的文件嵌套在很多文件夾中。我應該爲我的項目使用相對包含路徑，還是將include-directory放在包含路徑中？
例如，在我目前的項目中，我有network/server/myfile.hpp。它需要包括common/log.hpp。目前我使用#include "../../common/log.hpp"這是相當詳細，但工程。
如果我在路徑上添加主包含目錄，則可以簡單包含"common/log.hpp"。
我知道這個問題可能比其他任何東西更偏向於優先考慮，但是對於跨平臺應用程序和C++約定有什麼客觀的優點和缺點？
相對包含路徑與..在它看起來有點醜陋，並期望一定的文件系統結構，即"../../common/log.hpp"是兩個文件夾了。通常避免不必要的依賴關係，特別是文件系統結構是有意義的，因此將頭文件從一個目錄移動到另一個目錄不會強制您更新包含該頭的所有源文件。
使您的包含對應於命名空間和類也是優雅的。如果，例如，您有：
namespace foo { namespace bar { struct Baz; } }
這是方便和直觀，包括它喜歡：
#include "foo/bar/Baz.h"
我一直努力讓自己的項目獨立於位置。如果我在新的計算機/平臺上工作，我希望能夠編譯並繼續使用最少的必要設置工作。當你問一個主觀問題時，我的主觀答案是我絕對更喜歡使用相對路徑。
沒有約定，您可以按照您喜歡的方式任意選擇。
我的意思是，如果你想保持它的整潔 雖然那顯然去第二 選擇，我會自己去的第二 一個原因它不是你必須 移動一塊巨石，但只是幾個文件， 說主要。
而且相對路徑爲您提供自由端口您的應用程序，那麼就去做吧:)
通過在你的源文件#include <common/log.hpp>，不得不在您的項目設置common/log.hpp路徑（編譯器選項）你是保護您的源代碼免受更改，如果common/log.hpp移動到其他地方，我會推薦這種方法。注意在這種情況下使用尖括號 - 編譯器應搜索/I編譯器選項指定的目錄中的頭。
我有各個組件可能不使用多個目錄的規則，以及組件在包含路徑中具有相關組件的目錄。
因此，每個組件使用其自己的包括與""語法文件，以及其它組件的使用<>包括，這很好地避免了使用的最後一個部署的版本安裝到系統中的標題與一個部件不愉快的意外包括目錄，而不是源樹中的一個;它也具有迫使我儘早組件化的好效果。