为什么这会令人困惑#include“.. \ .. \ [等等]”声明有效？

我想一个的#include指令添加到我的A.cpp文件和头文件了Bh是文件夹两层起来（例如，如果源文件是* E：\ A \ B \ C \ D \ E \ F \ G \ H *，头文件在* E：\ A \ B \ C \ F *，当然名字会比这个长很多），所以我打在Visual Studio 2010年这一令人困惑的声明：为什么这会令人困惑#include“.. .. [等等]”声明有效？

#include"../../

而在VS 10智能感知功能显示了文件的列表，并了Bh就在里面！我不知道这个说法是否正确，但我认为这是有问题的。你能告诉我这是错的还是正确的？你能给我一个更好的解决方案吗？非常感谢。

来源

2013-07-29 Blip

你为什么觉得有什么问题？所有这些对我来说都是正确的。 –

也许是因为它很脆弱？ – Jiminion

它如何比编译器传递一个'-I'标志（或任何MSVC等价物）更脆弱？ –

为什么它不工作？你有没有完成cd ../../mydir，并检查了这是什么？这是相同的。 ..和.指向Windows和Linux中的特殊目录。 .是当前目录，而..是之前的目录。因此../../file.h会返回两个目录来查找您要查找的文件。毕竟，#include "..."语句的工作方式与文件位于相对路径。写库，你有一个主detail子目录通常当你将尝试通过#include "../detail/myfile.hpp"访问它，而其他库，如升压齐齐#include <boost/config/myfile.hpp>

来源

2013-07-29 16:56:14 Rapptz

谢谢你告诉我。这对你很好。 – Blip

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

来源

2013-07-29 16:55:40

我怎样才能包括这个？我可以使用VS 2010命令提示吗？ – Blip

转到您项目的属性，那里有一个包含选项。 –

根据Carl Norum发表的评论，我认为传递-I标志是一个更好的解决方案 – Blip

-1

..\让你向上移动一个目录，所以..\..\会移动你两个目录。如果你可以假设脚本的位置不会改变，我想这很好。但是，如果您将脚本移到另一个驱动器上，您将遇到麻烦。包括E：\ A \ B \ C \ D \ E \ F \ B.h可能会更好，而不是为了将来证明自己。

来源

2013-07-29 17:01:19 LoganGoesPlaces

当问题是关于C++时，你会说“脚本”。我无法想象什么样的程序员会建议硬编码本地包含路径，而不是使用相关的相对路径。 – DanielKO

我想我可以从Windows资源管理器粘贴这个文件位置，但是如果我改变位置，它将需要很大的努力来改变这个位置的所有引用。但我会感谢你的建议。 – Blip

@DanielKO我只是一般性地讲，因为这可能适用于任何数量的语言。基于这个问题，我们不知道项目的范围。我承认我认为这是基于问题本身的小规模，这是我的不好。我显然不会在生产环境中提倡这一点，但是在小范围内有什么危害。 – LoganGoesPlaces

为什么这会令人困惑#include“.. \ .. \ [等等]”声明有效？

回答

相关问题