实际需要的#include路径更长

are longer #include paths ever actually needed?

本文关键字：路径 #include 实际需要      更新时间：2023-10-16

例如，如果我有一个名为foo.h的文件，我可以通过执行以下操作来包含它吗：

#include "foo.h"

或者我有时必须做一些类似的事情：

#include "bar/foobar/foo.h"

编辑-它们只是用来通过限制对文件的搜索来缩短编译时间吗？

基本上，您可以将include路径作为选项传递给C++编译器，但它不会递归地查找文件。如果你通过路径/opt/include并执行"#include "foo.h""，它将只找到/opt/include/foo.h，而不是/opt/include/dummy/foo.h。

换句话说，您可以在命令行上传递所有可能的include路径，或者使用#include "dummy/foo.h" 传递root并"导航"

编辑：@MatthieuM。下面提出了另一个很好的观点，#include "mylibrary/api.h"使您使用的包含文件比#include "api.h"更清楚，尤其是当您使用多个库时。

编译器不会递归搜索源目录。如果要使用#include "foo.h"，则需要使用-Ibar/foobar进行编译，以告诉编译器应该在bar/foobar中查找头文件。

否则，您将不得不使用完整（相对）路径。与-I相比，我更喜欢它，因为它使源代码更独立于编译器标志（当在构建系统之间进行更改时，您会很欣赏这一点）。

可能存在多个具有相同名称的头文件的情况——在这种情况下，路径有助于消除歧义。

我认为这取决于您的项目设置，例如，您在Visual C++中有类似"Additional Include Directories"的部分，因此IDE也会搜索这些目录中的文件。

第一个语句#include"foo.h"将在当前工作目录或其他include目录下提到的目录中搜索foo.h。

如果您的头文件在其他路径中，则需要明确提及它。

相关文章：