为什么这个令人困惑的 #include"..\..\[etc. etc.]" 语句可以工作？答案

【问题标题】：Why can this confusing #include"..\..\[etc. etc.]" statement work?为什么这个令人困惑的 #include"..\..\[etc. etc.]" 语句可以工作？
【发布时间】：2013-07-29 16:53:15
【问题描述】：

我想在我的A.cpp文件中添加一个#include指令，头文件B.h在文件夹两层向上（例如，如果源文件在*E:\A\B\C\D\E\F\G\H*，则头文件在*E： \A\B\C\F*，当然名字会比这个长很多），所以我在 Visual Studio 2010 中输入了这个令人困惑的语句：

#include"../../

VS 10 中的 Intellisense 功能显示了文件列表，B.h 就在其中！我不知道这个说法是否正确，但我认为这有问题。你们谁能告诉我这是错误的还是正确的？你能给我一个更好的解决方案吗？非常感谢。

【问题讨论】：

为什么你认为有问题？所有这些对我来说似乎都是正确的。
可能是因为它很脆弱？
它比必须将-I 标志（或任何与MSVC 等效的标志）传递给编译器相比更脆弱吗？
我是否必须将此标志传递给 VS 2010 命令提示符？

标签： c++ file visual-c++ include directive

【解决方案1】：

为什么它不起作用？你有没有做过cd ../../mydir 并检查过它的作用？它相当于那个。 .. 和 . 指向 Windows 和 Linux 中的一个特殊目录。 . 是当前目录，.. 是前一个目录。所以../../file.h 会返回两个目录来查找您要查找的文件。毕竟，#include "..." 语句适用于文件所在的相对路径。通常在编写库并且您有一个主要的detail 子目录时，您会尝试通过#include "../detail/myfile.hpp" 访问它，而其他库，例如 boost opt为#include <boost/config/myfile.hpp>

【讨论】：

【解决方案2】：

我认为最好将"-I <INCLUDE_DIR>" 参数包含到您的构建中，并且只需#include 标头而不列出目录。这是您告诉编译器和链接器查找头文件的地方。

【讨论】：

我怎样才能包含这个？我可以使用 VS 2010 命令提示符吗？
转到您项目的属性，那里有一个包含选项。
根据 Carl Norum 的评论，我认为传递 -I 标志是一个更好的解决方案

【解决方案3】：

..\ 将您上移一个目录，因此..\..\ 会将您上移两个目录。如果您可以假设脚本位置永远不会改变，我想这很好。但是，如果您将脚本移动到不同的驱动器，您将遇到麻烦。最好包含 E:\A\B\C\D\E\F\B.h 而不是自己将来证明。

【讨论】：

当问题是关于 C++ 时，您会说“脚本”。我无法想象什么样的程序员会建议硬编码本地包含路径而不是使用连贯的相对路径。
我想我可以从 Windows 资源管理器中粘贴此文件位置，但如果我更改位置，则需要花费大量精力来更改此位置的所有引用。但我会感谢你的建议。
@DanielKO 我只是笼统地说，因为这可能适用于任何数量的语言。基于这个问题，我们不知道该项目的范围。我承认我认为这是基于问题本身的小规模，这是我的错。我显然不会在生产环境中提倡这样做，但是小规模的东西有什么危害。
@VictorPrograss 如果项目被移动，您将遇到同样的问题，即必须使用任一技术更新路径。为什么不在项目的子目录中包含必要的文件，而不是遍历层次结构来查找文件？然后，您可以确定像 /resources/B.h 这样的相对路径将始终指向您的文件，即使它移动了。