#include "xxx.h" 的规则是什么？与 #include 相比？

Question

如果我有自己的库项目，我应该使用哪种样式在我的应用程序中 #include 它们的标头？是否有严格的规则，两者对编译器/预处理器实际上有不同的含义还是仅与标准有关？

Answer 1

根据 ISO 标准，规则很少。两种形式都依赖于实现，它们在哪里查找头文件。它们甚至不必是文件。

C++11 的 2.9 节对这两个变体没有区别，只是您可以在 <> 变体中包含 "和 "" 变体中的 > 但很少有人会愚蠢到在文件名中使用这些字符:-)

第 16.2 节进一步说明:

---

格式为# include <的预处理指令h-字符序列> new-line 在一系列实现定义的位置中搜索由 < 和 > 分隔符之间的指定序列唯一标识的标头，并导致用标头的全部内容替换该指令。如何指定位置或识别标头是实现定义的。

# include " q-char-sequence" new-line 形式的预处理指令会导致将该指令替换为由 < 之间的指定序列标识的源文件的全部内容。 code>" 分隔符。以实现定义的方式搜索指定的源文件。如果不支持此搜索，或者搜索失败，则重新处理指令，就像读取 # include < ; h-char-sequence> new-line 与原始指令中的相同包含序列（包括 > 字符，如果有）。

---

我倾向于使用 <> 作为系统标头和 < code>"" 作为我自己的标题，但这只是个人偏好，我会注意到前面提到的 C++11 文档指出：

注意：虽然实现可能提供一种机制，使任意源文件可用于 <> 搜索，但一般来说，程序员应该使用 <>用于随实现提供的标头的表单，以及用于不受实现控制的源的 "" 表单。

这不是强制性的，但仍然是一个好主意。

Answer 2

通常，通过使用引号，您的意思是头文件位于项目目录的相对位置。另一方面，如果您使用尖括号，编译器会期望您的头文件位置为标准位置。例如 /usr/include、/usr/local/include 或编译器的任何其他默认位置。

在 GCC 中，如果使用 -I 标志，则包含尖括号的内容也会在指定位置进行搜索。

示例：

$ gcc -Wall -I/path/to/my/library/include myfile.c

因此，如果 /path/to/my/library/include 中有 myfile.h，则可以使用 #include < /code> 在 myfile.c 源中。

Answer 3

在几个不同的操作系统上使用了数十个编译器之后，我的建议是仅对系统和特定于操作的标头包含使用 ，而使用 "yh"其他所有内容，包括您的库和项目标头。

然后，使用编译器的 -I （或其他）选项设置适当的包含搜索路径。如果您使用 make 或 ant 之类的东西来进行构建，这会更容易。

对于第三方软件标头，您可以使用任一形式。如果该软件包已安装并且所有用户都可以访问（例如，在 /usr/local/bin 或 /usr/site/bin 等位置），则 形式可能更正确。如果它安装在本地构建树中，则 "yh" 形式更正确，因为它是在构建过程中控制的。

这种组合是最便携的。

Answer 4

它影响预处理器搜索包含文件的位置。来自 MSDN：

“引用形式：此形式指示预处理器在包含 #include 语句的文件的同一目录中查找包含文件，然后在包含 (#include) 该文件的任何文件的目录中查找包含文件。预处理器然后沿着 /I 编译器选项指定的路径搜索，然后沿着 INCLUDE 环境变量指定的路径搜索

：此形式指示预处理器首先沿着 /I 编译器选项指定的路径搜索包含文件，然后，当从命令行编译时，沿着 INCLUDE 环境变量指定的路径。”

作为粗略指南，当我尝试指定相对于包含带有 #include 的文件的目录的路径时，我仅使用引号。否则，我只使用尖括号。以我当前项目为例：

#include <algorithm> // standard library headers
#include <numeric>
#include <stack>

#include <boost/function.hpp> // third-party library headers
#include <boost/lexical_cast.hpp>

#include <common/io/util/LineIO.h> // specified relative to my own base include dir
#include "PartitionForest.h" // a header in the current directory