#include 父目录的文件答案

【问题标题】：#include parent directory's file#include 父目录的文件
【发布时间】：2013-02-27 19:10:54
【问题描述】：

我的文件夹结构是

libA
    x.h
    y.h
    algorithm/
        a.h

现在在a.h 我有#include "libA/x.h" 不工作。它正在搜索algorithm/libA/x.h。那么我应该使用 #include "../x.h" 吗？第二种选择是一个糟糕的设计吗？目前 libA 只是标题。但后者我可能会选择将其编译为库

我正在使用 cmake 那么我可以或应该在我的包含路径中添加 libA 吗？

总之

我的算法目录中的一些文件需要包含其父文件夹中的定义。我不能将所有函数都模板化，因为类型很明显，而且会过度。那么我应该如何设计我的项目呢？

【问题讨论】：

“那么我应该使用#include "../x.h” - 你试过了吗？
您的编译器（或更准确地说是预处理器）对路径有何看法？
我正在使用 gcc，但它也应该适用于 msvc。但我从未见过这些编译器在#include 中拒绝../
@DiproSen 我的答案已被删除，没有发表评论。我希望它在那里时有用。作为对您的评论的回应，我会检查算法是否真的依赖于 x 和 y，还是依赖于这些类所呈现的特征？
我可以将算法中的函数模板化。但在某些情况下，类型很明显，将这些函数模板化将是过度的。所以我需要包括在内。但我还需要对算法相关文件进行分组

【解决方案1】：

您使用#include "../x.h" 的解决方案将起作用。关于这是否是糟糕的设计——可能是；在不了解您的代码的情况下很难分辨。

考虑一个事实，如果您有许多包含路径，编译器/预处理器将查找 ../x.h 是所有这些路径，这可能是无意且过于宽泛的！

假设您具有以下目录结构，并且Your_Code 在包含文件的搜索路径中。

Unrelated_Directory/
    x.h - unrelated
    Your_Code/
        libA/
            x.h - the real one
            algorithm/
                a.h

这很危险。如果你删除/重命名你的真实x.h，编译器会默默地选择Your_Code/../x.h，其中包含不相关的东西——这可能会导致神秘的错误消息。或者更糟糕的是，这可能是一个旧版本，漏洞百出！

【讨论】：

【解决方案2】：

在制作我知道我会在其他项目中使用的库时，我倾向于使用 boost 的包含样式：

#include <libA/x.h>

这意味着只要“libA”（可能是/include）上方的文件夹存在，您就可以使用“libA”引用下面的任何内容。它还有助于避免在包含 boost 样式的内容时出现类似命名的包含文件的冲突，因为在您的库中以及在库的标题和其他相关代码之外，您总是指定要从中提取“x.h”的库，例如

#include <SexyLib/x.h> // Two different x.h
#include <TheLibFarAway/x.h>  // but same name! I hope you also have Namespaces :D

这只是个人喜好，但它似乎对我正在开发的库和boost 也很有效。希望对您有所帮助！

【讨论】：

#include <libA/x.h> 也不起作用。它抱怨没有这样的文件。现在，如果我添加 INCLUDE PATH libA 用户将需要执行相同操作，否则将无法编译
@DiproSen 好吧，考虑一下。你也必须对 boost 做同样的事情；您将顶层 boost 文件夹添加到您的 INCLUDE PATH，然后使用 #include <boost/[whatever]>。除非用户将您的 lib 文件添加到编译器始终搜索的基本文件夹（大多数用户通常不这样做），否则无法避免这种情况。因此，只需告诉他们添加该包含目录即可；这是你能做的最好的。
但是没有人可以只是将文件夹复制粘贴到子目录中并开始使用它。

【解决方案3】：

如果您使用的是 gcc，您可以添加 -IPathTo/libA 以将 libA 添加到文件夹列表中，然后使用 #include "x.h"

【讨论】：