17

在我的项目中，我目前使用相对路径来包含我的文件，诚然这不会经常更改。但是，它会产生非常奇怪的包含模式，因为我通常将文件嵌套在很多文件夹中。

例如，在我当前的项目中，我有network/server/myfile.hpp. 它需要包括common/log.hpp. 我使用的电流#include "../../common/log.hpp"非常冗长，但有效。

如果我改为在路径上添加我的主包含目录，我可以简单地包含"common/log.hpp".

我知道这个问题可能更多的是关于偏好，但是关于跨平台应用程序是否有任何客观的利弊以及 C++ 约定呢？

4

5 回答 5

12

相对的包含路径..看起来有点难看，并期望某种文件系统结构，即"../../common/log.hpp"两个文件夹。一般来说，避免不必要的依赖是有意义的，尤其是在文件系统结构上，因此将头文件从一个目录移动到另一个目录不会强制您更新包含该头文件的所有源文件。

让您的包含与命名空间和类相对应也很优雅。例如，如果您有：

namespace foo { namespace bar { struct Baz; } }

将其包括在内既方便又直观：

#include "foo/bar/Baz.h"
于 2011-02-15T17:11:35.967 回答
5

通过#include <common/log.hpp>在您的源文件中并在您的项目设置（编译器选项）中有路径，common/log.hpp您可以保护您的源代码免受更改，以防万一common/log.hpp移动到其他地方，所以我会推荐这种方法。/I请注意在这种情况下使用尖括号 - 编译器应在编译器选项指定路径的目录中搜索头文件。

于 2011-02-15T17:09:27.640 回答
2

我总是努力让我的项目不受地点的影响。如果我在新的计算机/平台上工作，我希望能够编译并继续使用最少的所需设置。当您问一个主观问题时，我的主观答案是我绝对更喜欢使用相对路径。

于 2011-02-15T17:01:57.780 回答
1

没有这样的约定，您可以按照您喜欢的方式进行操作。

我的意思是，如果你想保持整洁，那么显然选择第二个选项，我自己会选择第二个，因为它不是你必须移动一块巨石，而只是几个文件，比如 main。

此外，相对路径为您提供了移植应用程序的自由，所以就这样做吧:)

于 2011-02-15T17:02:08.047 回答
0

我有一条规则，每个单独的组件不能使用多个目录，并且该组件在包含路径中具有依赖组件的目录。

因此，每个组件都使用自己的包含文件和""语法，而其他组件的 include 文件使用 using <>，这很好地避免了一个组件使用安装到系统包含目录中的最后一个部署版本的头文件而不是源代码树中的头文件的令人不快的意外; 它还有一个很好的效果，它迫使我尽早将我的项目组件化。

于 2011-02-15T17:18:06.587 回答