我应该为我的项目使用相对包含路径，还是将include-directory放在包含路径中？
在我的项目中，我目前使用相对路径来包含我的文件，但这些文件并不经常更改。但是，它会产生很奇怪的包含模式，因为我通常将我的文件嵌套在很多文件夹中。我应该为我的项目使用相对包含路径，还是将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编译器选项指定的目录中的头。
我有各个组件可能不使用多个目录的规则，以及组件在包含路径中具有相关组件的目录。
因此，每个组件使用其自己的包括与""语法文件，以及其它组件的使用<>包括，这很好地避免了使用的最后一个部署的版本安装到系统中的标题与一个部件不愉快的意外包括目录，而不是源树中的一个;它也具有迫使我尽早组件化的好效果。