Question

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

Answer 1

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

C ++ 11的2.9部分除了"变体中的<>和>中的""之外，两个变量之间没有区别。 {1}}变体，但很少有人会愚蠢地在文件名中使用这些字符： - ）

第16.2节进一步指出：

# include < h-char-sequence> new-line形式的预处理指令搜索一系列实现定义的位置，以查找由<和>分隔符之间的指定序列唯一标识的标头，并导致替换该指令的标题的全部内容。如何指定场所或标识的标题是实现定义的。

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

我倾向于将<>用于系统标头，将""用于我自己的标头，但这只是个人偏好。我会注意到前面提到的C ++ 11文档声明：

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

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

Answer 2

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

如果您使用-I标记，则在 GCC 中，也会在指定位置搜索包含尖括号的包含。

示例：

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

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

Answer 3

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

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

Angle-bracket形式：此表单指示预处理器首先沿/ 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

Answer 4

在几个不同的操作系统上使用过几十个编译器后，我的建议是仅将<x.h>用于系统和特定于操作的标头包含，并将"y.h"用于其他所有操作系统，包括您的库和项目头。

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

对于第三方软件标题，您可以选择任何一种形式。如果所有用户都安装了该软件包并且可以访问该软件包（例如，在/usr/local/bin或/usr/site/bin之类的某个位置），则<x.h>表单可能更正确。如果它安装在您的本地构建树中，则"y.h"表单更正确，因为它在您的构建过程中受到控制。

这种组合是最便携的。

有关#include“xxx.h”的规则是什么#slude <xxx.h>？</xxx.h>

4 个答案: