在我的项目中，我目前使用相对路径来包含我的文件，这些文件肯定不会经常更改。然而，它产生了非常奇怪的包含模式，因为我通常将我的文件嵌套在很多文件夹中。
例如，在我当前的项目中，我有network/server/myfile.hpp。它需要包含common/log.hpp。目前我使用的#include "../../common/log.hpp"非常详细，但有效。
如果我改为在路径上添加我的主要包含目录，我可以简单地包含"common/log.hpp"。
我知道这个问题可能更多是关于偏好而不是其他任何问题，但是关于跨平台应用程序有什么客观利弊以及C ++约定怎么样？
答案 0 :(得分：12)
相对包含..的路径看起来有点难看并期望某个文件系统结构，即"../../common/log.hpp"是两个文件夹。有意义的是，通常避免不必要的依赖关系，特别是文件系统结构，因此将头文件从一个目录移动到另一个目录不会强制您更新包含该头的所有源文件。
让您的包含对应于命名空间和类也很优雅。例如，如果你有：
namespace foo { namespace bar { struct Baz; } }
将其包括在内是方便直观的：
#include "foo/bar/Baz.h"
答案 1 :(得分：5)
通过在源文件中包含#include <common/log.hpp>并在项目设置（编译器选项）中拥有common/log.hpp的路径，您可以保护源代码免受common/log.hpp移动到其他位置的更改所以我会推荐这种方法。注意在这种情况下使用尖括号 - 编译器应该在目录中搜索哪个路径由/I编译器选项指定。
答案 2 :(得分：2)
我总是努力让我的项目独立于位置。如果我在新的计算机/平台上工作，我希望能够编译并继续使用最少的必要设置。当你提出一个主观问题时，我的主观答案是我绝对更喜欢使用相对路径。
答案 3 :(得分：1)
没有这样的公约，你可以按照自己喜欢的方式进行。
我的意思是，如果你想保持整洁 虽然然后显然是第二 选项，我自己去第二个 一个因为它不是你必须的 移动一块巨石，但只有几个文件， 说主要。
而且相对路径为您提供了移植应用程序的自由，所以就这样做：）
答案 4 :(得分：0)
我有一条规则，即每个单独的组件可能不会使用多个目录，并且该组件在包含路径中具有依赖组件的目录。
因此，每个组件使用自己的包含""语法的包含文件，其他组件包括使用<>，这很好地避免了一个组件使用最后部署的版本安装的标头的令人不快的意外进入系统包括目录而不是源树中的目录;它也有很好的效果，迫使我尽早组织我的项目。