#include <文件名> 和 #include <文件名> 有什么区别？ 和#include“文件名”？

滴情不沾 2024-07-11 10:10:45

一般来说，区别在于预处理器搜索头文件的位置：

#include 是包含头文件的预处理器指令。 #include 都用于在程序中添加或包含头文件，但第一个是包含系统头文件，后面一个是用于用户定义的头文件。

#include是用于在程序中包含系统库头文件，意味着C/C++预处理器将搜索存储C库文件或预定义系统头文件的文件名。
#include "filename" 用于在程序中包含用户定义的头文件，表示 C/C++ 预处理器将在程序所在的当前目录中搜索文件名，然后按照所使用的搜索路径进行搜索对于 #include <文件名>

检查 gcc 文档 gcc 包含文件< /a>

回复收藏 0 原文

冷情妓 2024-07-11 10:10:45

< 之间的字符序列和> 唯一引用一个标头，它不一定是一个文件。实现可以按照自己的意愿自由地使用字符序列。（但是，大多数情况下，只需将其视为文件名并在包含路径中进行搜索，如其他帖子所述。）

如果 #include "file" 形式使用时，实现首先查找给定名称的文件（如果支持）。如果不支持（支持），或者搜索失败，则实现的行为就像使用其他（#include）形式一样。

此外，还存在第三种形式，当 #include 指令与上述任一形式都不匹配时使用。在这种形式中，对#include 指令的“操作数”进行了一些基本的预处理（例如宏扩展），并且结果预计与其他两种形式之一匹配。

回复收藏 0 原文

枯寂 2024-07-11 10:10:45

#include <filename>

当你想使用C/C++系统的头文件或编译器库时使用。这些库可以是 stdio.h、string.h、math.h 等。

#include "path-to-file/filename"

当您想要使用位于项目文件夹或其他位置的自定义头文件时，可以使用这些库。

有关预处理器和标头的更多信息。阅读C - 预处理器。

回复收藏 0 原文

合约呢 2024-07-11 10:10:45

#include

预处理器以依赖于实现的方式进行搜索。它告诉编译器搜索保存系统头文件的目录。
该方法通常用于查找标准头文件。

#include "filename"

这告诉编译器搜索程序运行的头文件。如果失败，其行为类似于 #include 并在存储系统头文件的位置搜索该头文件。
该方法通常用于识别用户定义的头文件（由用户创建的头文件）。如果您想调用标准库，请不要使用此选项，因为它比 #include 花费更多的编译时间。

回复收藏 0 原文

眼眸印温柔 2024-07-11 10:10:45

“”在标准 C 库位置中搜索
而“文件名”也在当前目录中搜索。

理想情况下，您会使用 <...> 对于标准 C 库，“...”对于您编写的并存在于当前目录中的库。

回复收藏 0 原文

忆依然 2024-07-11 10:10:45

#include 在引用系统文件时使用。这是一个头文件，可以在系统默认位置（例如 /usr/include 或 /usr/local/include）找到。对于需要包含在另一个程序中的您自己的文件，您必须使用 #include "filename" 语法。

回复收藏 0 原文

离旧人 2024-07-11 10:10:45

表格 1 - #include < xxx>

首先，在调用指令的当前目录中查找头文件是否存在。如果未找到，则会在预配置的标准系统目录列表中进行搜索。

形式 2 - #include "xxx"

这会在调用指令的当前目录中查找是否存在头文件。

确切的搜索目录列表取决于目标系统、GCC 的配置方式以及安装位置。
您可以通过使用 -v 选项运行 GCC 编译器来找到其搜索目录列表。

您可以使用 - Idir 将其他目录添加到搜索路径，这会导致在当前目录之后（对于指令的引号形式）和标准系统目录之前搜索 dir。

基本上，“xxx”的形式只不过是在当前目录中搜索；如果没有发现退回表格

回复收藏 0 原文

何必那么矫情 2024-07-11 10:10:45

简单的一般规则是使用尖括号来包含编译器附带的头文件。使用双引号包含任何其他头文件。大多数编译器都是这样做的。

1.9 — 头文件详细说明有关预处理器指令的详细信息。如果您是新手程序员，该页面应该可以帮助您理解所有这些。我是从这里学到的，并且在工作中也一直遵循着它。

回复收藏 0 原文

在风中等你 2024-07-11 10:10:45

不同之处在于预处理器搜索要包含的文件的位置。

#include <文件名> 预处理器以实现定义的方式进行搜索，通常在编译器/IDE 预先指定的目录中进行搜索。此方法通常用于包含 C 标准库的头文件以及与目标平台相关的其他头文件。
#include“文件名” 预处理器还以实现定义的方式进行搜索，但通常用于包含程序员定义的头文件，并且通常包含与包含指令的文件相同的目录（除非给出绝对路径）。

对于 GCC，更完整的描述可以在 GCC 搜索路径文档。

回复收藏 0 原文

梦途 2024-07-11 10:10:45

唯一了解的方法是阅读您的实现文档。

在C 标准中，第 6.10.2 节第 2 至 4 段规定：

表单的预处理指令
#include ;   新队 
  
在一系列实现定义的位置中搜索由 < 和 > 分隔符之间的指定序列唯一标识的标头，并导致该指令被标头的全部内容替换。如何指定位置或识别标头是实现定义的。
表单的预处理指令
#include "q-char-sequence" 换行符 
  
导致将该指令替换为由 " 分隔符之间的指定序列标识的源文件的全部内容。指定的源文件，如果不支持此搜索，或者搜索失败，则将重新处理该指令，就像它读取的那样。
#include ;   新队 
  
具有与原始内容相同的包含序列（包括 > 字符，如果有的话）
指令。
表单的预处理指令
#include pp-tokens 换行符
允许
（与前面两种形式之一不匹配）。指令中 include 之后的预处理标记的处理方式与普通文本中一样。（当前定义为宏名称的每个标识符都被其预处理标记的替换列表所替换。）所有替换后产生的指令应与前面两种形式之一匹配。将 < 和 > 预处理标记对或一对 " 字符之间的预处理标记序列组合成的方法单个标头名称预处理标记是实现定义的。
定义：
h-char：除换行符和 > 之外的源字符集的任何成员
q-char：源字符集的任何成员，除了换行符和 "

The only way to know is to read your implementation's documentation.

In the C standard, section 6.10.2, paragraphs 2 to 4 state:

A preprocessing directive of the form
#include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
A preprocessing directive of the form
#include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
#include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original
directive.
A preprocessing directive of the form
#include pp-tokens new-line
(that does not match one of the two previous forms) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text. (Each identifier currently defined as a macro name is replaced by its replacement list of preprocessing tokens.) The directive resulting after all replacements shall match one of the two previous forms. The method by which a sequence of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined into a single header name preprocessing token is implementation-defined.
Definitions:
h-char: any member of the source character set except the new-line character and >
q-char: any member of the source character set except the new-line character and "

回复收藏 0 原文

流星番茄 2024-07-11 10:10:45

按照标准 - 是的，它们是不同的：

表单的预处理指令
#include ;   新队 
  
在一系列实现定义的位置中搜索由 < 和 > 分隔符之间的指定序列唯一标识的标头，并导致替换该指令由标题的全部内容组成。如何指定位置或识别标头是实现定义的。
表单的预处理指令
#include "q-char-sequence" 换行符 
  
导致将该指令替换为由 " 分隔符之间的指定序列标识的源文件的全部内容。以实现定义的方式搜索指定的源文件。如果此不支持搜索，或者如果搜索失败，该指令将被重新处理，就像它读取的一样
#include ;   新队 
  
具有与原始内容相同的包含序列（包括 > 字符，如果有的话）
指令。
表单的预处理指令
#include pp-tokens 换行符 
  
允许
（与前面两种形式之一不匹配）。指令中 include 之后的预处理标记的处理方式与普通文本中一样。（当前定义为宏名称的每个标识符都被其预处理标记的替换列表所替换。）所有替换后产生的指令应与前面两种形式之一匹配。将 < 和 > 预处理标记对或一对 " 字符之间的预处理标记序列组合成的方法单个标头名称预处理标记是实现定义的。
定义：
h-char：除换行符和 > 之外的源字符集的任何成员
q-char：源字符集的任何成员，除了换行符和 "

请注意，该标准没有说明实现定义的方式之间的任何关系。第一种形式以一种实现定义的方式进行搜索，另一种形式以（可能是其他）实现定义的方式进行搜索。该标准还指定应存在某些包含文件（例如，）。

正式来说，您必须阅读编译器的手册，但通常（按照传统）#include "..." 形式会搜索 #include< 所在文件的目录。首先找到/code>，然后是#include <...> 形式搜索的目录（包含路径，例如系统头文件）。

By the standard - yes, they are different:

A preprocessing directive of the form
#include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
A preprocessing directive of the form
#include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
#include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original
directive.
A preprocessing directive of the form
#include pp-tokens new-line
(that does not match one of the two previous forms) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text. (Each identifier currently defined as a macro name is replaced by its replacement list of preprocessing tokens.) The directive resulting after all replacements shall match one of the two previous forms. The method by which a sequence of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined into a single header name preprocessing token is implementation-defined.
Definitions:
h-char: any member of the source character set except the new-line character and >
q-char: any member of the source character set except the new-line character and "

Note that the standard does not tell any relation between the implementation-defined manners. The first form searches in one implementation-defined way, and the other in a (possibly other) implementation-defined way. The standard also specifies that certain include files shall be present (for example, <stdio.h>).

Formally you'd have to read the manual for your compiler, however normally (by tradition) the #include "..." form searches the directory of the file in which the #include was found first, and then the directories that the #include <...> form searches (the include path, eg system headers).

回复收藏 0 原文

疯了 2024-07-11 10:10:45

要根据当前配置使用 gcc 查看系统上的搜索顺序，可以执行以下命令。找到有关此命令的更多详细信息

您可以在此处 cpp - v /dev/null -o /dev/null

Apple LLVM 版本 10.0.0 (clang-1000.10.44.2)
目标：x86_64-apple-darwin18.0.0
线程模型：posix InstalledDir：Library/Developer/CommandLineTools/usr/bin
“/Library/Developer/CommandLineTools/usr/bin/clang”-cc1 -三重
x86_64-apple-macosx10.14.0 -W已弃用-objc-isa-用法
-Werror=已弃用-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -主文件名 null -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -目标链接器版本 409.12 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 -isysroot
/库/开发人员/CommandLineTools/SDKs/MacOSX10.14.sdk
-I/usr/local/include -fdebug-compilation-dir /Users/hogstrom -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx- 10.14.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics-traditional-cpp -o - -xc /dev/null
clang -cc1 版本 10.0.0 (clang-1000.10.44.2) 默认目标 x86_64-apple-darwin18.0.0 忽略
不存在的目录“/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/local/include”
忽略不存在的目录“/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks”
#include "..." 搜索从此处开始：
#include <...> 搜索从这里开始：
/usr/local/include
/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0/include
/Library/Developer/CommandLineTools/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks（框架目录）
搜索列表结束。

回复收藏 0 原文

场罚期间 2024-07-11 10:10:45

#include 语句有两种编写方式。它们是：

#include"filename"
#include<filename>

每种形式的含义是

#include"mylib.h"

该命令将在当前目录以及前面提到的指定目录列表中查找文件 mylib.h n 可能已设置的包含搜索路径。

#include<mylib.h>

此命令将仅在指定的目录列表中查找文件mylib.h。

包含搜索路径只不过是要搜索要包含的文件的目录列表。不同的 C 编译器允许您以不同的方式设置搜索路径。

There exists two ways to write #include statement.These are:

#include"filename"
#include<filename>

The meaning of each form is

#include"mylib.h"

This command would look for the file mylib.h in the current directory as well as the specified list of directories as mentioned n the include search path that might have been set up.

#include<mylib.h>

This command would look for the file mylib.h in the specified list of directories only.

The include search path is nothing but a list of directories that would be searched for the file being included.Different C compilers let you set the search path in different manners.

回复收藏 0 原文

活雷疯 2024-07-11 10:10:45

编译器生成的实现定义的警告可以（并且将会）以不同于程序库的方式对待系统库。

所以

#include

——实际上声明 myFilename 位于系统库位置——很可能（并且可能会）隐藏死代码和未使用的变量警告等，这些都会显示出来当您使用：

#include "myFilename"

回复收藏 0 原文

青萝楚歌 2024-07-11 10:10:45

这里的许多答案都集中在编译器将搜索以查找文件的路径。虽然这是大多数编译器所做的，但允许使用标准头的效果对符合标准的编译器进行预编程，并将 #include 视为一个开关，并且它需要根本不作为文件存在。

这并不纯粹是假设。至少有一个编译器以这种方式工作。建议仅将 #include 与标准标头一起使用。

回复收藏 0 原文

染柒℉ 2024-07-11 10:10:45

#include <> 用于预定义头文件

如果头文件是预定义的，那么您只需将头文件名写在尖括号中，它看起来像这样（假设我们有一个预定义的头文件名称 iostream）：

#include <iostream>

#include " " 用于程序员定义的头文件

如果您（程序员）编写了自己的头文件，那么您会将头文件名写在引号中。因此，假设您编写了一个名为 myfile.h 的头文件，那么这是如何使用 include 指令来包含该文件的示例：

#include "myfile.h"

#include <> is for predefined header files

If the header file is predefined then you would simply write the header file name in angular brackets, and it would look like this (assuming we have a predefined header file name iostream):

#include <iostream>

#include " " is for header files the programmer defines

If you (the programmer) wrote your own header file then you would write the header file name in quotes. So, suppose you wrote a header file called myfile.h, then this is an example of how you would use the include directive to include that file:

#include "myfile.h"

回复收藏 0 原文

悲欢浪云 2024-07-11 10:10:45

#include "filename" // User defined header
#include <filename> // Standard library header.

示例：

此处的文件名是 Seller.h：

#ifndef SELLER_H     // Header guard
#define SELLER_H     // Header guard

#include <string>
#include <iostream>
#include <iomanip>

class Seller
{
    private:
        char name[31];
        double sales_total;

    public:
        Seller();
        Seller(char[], double);
        char*getName();

#endif

在类实现中（例如 Seller.cpp），以及将使用文件 Seller.cpp 的其他文件中。 h），现在应该包含用户定义的标头，如下所示：

#include "Seller.h"

#include "filename" // User defined header
#include <filename> // Standard library header.

Example:

The filename here is Seller.h:

#ifndef SELLER_H     // Header guard
#define SELLER_H     // Header guard

#include <string>
#include <iostream>
#include <iomanip>

class Seller
{
    private:
        char name[31];
        double sales_total;

    public:
        Seller();
        Seller(char[], double);
        char*getName();

#endif

In the class implementation (for example, Seller.cpp, and in other files that will use the file Seller.h), the header defined by the user should now be included, as follows:

#include "Seller.h"

回复收藏 0 原文

一曲琵琶半遮面シ 2024-07-11 10:10:45

#include <abc.h>

用于包含标准库文件。因此编译器将检查标准库头所在的位置。

#include "xyz.h"

会告诉编译器包含用户定义的头文件。因此编译器将在当前文件夹或 -I 定义的文件夹中检查这些头文件。

#include <abc.h>

is used to include standard library files. So the compiler will check in the locations where standard library headers are residing.

#include "xyz.h"

will tell the compiler to include user-defined header files. So the compiler will check for these header files in the current folder or -I defined folders.

回复收藏 0 原文

蓝礼 2024-07-11 10:10:45

"" 将首先搜索 ./。然后搜索默认包含路径。
您可以使用这样的命令来打印默认包含路径：

gcc -v -o a a.c

以下是一些示例，可以使事情更清楚：
代码 ac 可以工作，

// a.c
#include "stdio.h"
int main() {
        int a = 3;
        printf("a = %d\n", a);
        return 0;

}

bc 代码也可以工作，

// b.c
#include <stdio.h>
int main() {
        int a = 3;
        printf("a = %d\n", a);
        return 0;

}

但是当我在当前目录中创建一个名为 stdio.h 的新文件时

// stdio.h
inline int foo()
{
        return 10;
}

ac 会生成编译错误，但是 bc< /code> 仍然有效

，并且 "", <> 可以与相同的文件名一起使用。因为搜索路径优先级不同。
所以 dc 也有效

// d.c
#include <stdio.h>
#include "stdio.h"
int main()
{
        int a = 0;

        a = foo();

        printf("a=%d\n", a);

        return 0;
}

"" will search ./ first. Then search the default include path.
You can use command like this to print the default include path:

gcc -v -o a a.c

Here are some examples to make thing more clear:
the code a.c works

// a.c
#include "stdio.h"
int main() {
        int a = 3;
        printf("a = %d\n", a);
        return 0;

}

the code of b.c works too

// b.c
#include <stdio.h>
int main() {
        int a = 3;
        printf("a = %d\n", a);
        return 0;

}

but when I create a new file named stdio.h in current directory

// stdio.h
inline int foo()
{
        return 10;
}

a.c will generate compile error, but b.c still works

and "", <> can be used together with the same file name. since the search path priority is different.
so d.c also works

// d.c
#include <stdio.h>
#include "stdio.h"
int main()
{
        int a = 0;

        a = foo();

        printf("a=%d\n", a);

        return 0;
}

回复收藏 0 原文

看轻我的陪伴 2024-07-11 10:10:45

#include <file>

包含默认包含目录所在的文件。

#include "file"

包含编译该文件的当前目录中的文件。双引号也可以指定到不同位置的完整文件路径。

#include <file>

Includes a file where the default include directory is.

#include "file"

Includes a file in the current directory in which it was compiled. Double quotes can specify a full file path to a different location as well.

回复收藏 0 原文

微暖i 2024-07-11 10:10:45

在 C++ 中，包含文件有两种方式：

第一种是 #include，它告诉预处理器在预定义的默认位置查找文件。
此位置通常是一个 INCLUDE 环境变量，表示包含文件的路径。

第二种类型是#include“文件名”，它告诉预处理器首先在当前目录中查找文件，然后在用户设置的预定义位置中查找它。

回复收藏 0 原文

请别遗忘我 2024-07-11 10:10:45

带有尖括号的 #include 将搜索“依赖于实现的位置列表”（这是表示“系统头”的一种非常复杂的方式）以查找要包含的文件。

带引号的 #include 只会搜索文件（并且“以依赖于实现的方式”，bleh）。这意味着，用普通英语来说，它将尝试应用您输入的路径/文件名，并且不会在前面添加系统路径或以其他方式篡改它。

另外，如果 #include "" 失败，则会重新读取为 #include <> 按标准。

gcc 文档有一个（特定于编译器的）描述，尽管特定于gcc 而不是标准，比 ISO 标准的律师式谈话更容易理解。

回复收藏 0 原文

余厌 2024-07-11 10:10:45

对于#include ""，编译器通常会搜索包含该 include 的文件的文件夹，然后搜索其他文件夹。对于#include <>，编译器不会搜索当前文件的文件夹。

回复收藏 0 原文

半透明的墙 2024-07-11 10:10:45

感谢您的精彩回答，尤其是。 Adam Stelmaszczyk 和 piCookie 以及 aib。

像许多程序员一样，我使用了非正式约定，即对应用程序特定文件使用 "myApp.hpp" 形式，对库和库使用形式。编译器系统文件，即在 /I 和 INCLUDE 环境变量中指定的文件，多年来一直认为这是标准。

然而，C 标准规定搜索顺序是特定于实现的，这会使可移植性变得复杂。更糟糕的是，我们使用 jam，它会自动找出包含文件的位置。您可以对包含文件使用相对或绝对路径。即

#include "../../MyProgDir/SourceDir1/someFile.hpp"

旧版本的 MSVS 需要双反斜杠 (\\)，但现在不需要。我不知道什么时候改变了。只需使用正斜杠即可与 'nix 兼容（Windows 会接受）。

如果您真的担心它，请使用“./myHeader.h”作为与源代码位于同一目录中的包含文件（我当前的非常大的项目有一些重复的包含文件名分散在各处——确实是一个配置管理问题）。

为了方便起见，这里复制了 MSDN 说明）。

引用表格
预处理器按以下顺序搜索包含文件：
与包含 #include 语句的文件位于同一目录中。
在当前打开的包含文件的目录中，按照相反的顺序
它们被打开了。搜索从父包含文件的目录开始，并且
继续向上遍历任何祖父母包含文件的目录。
沿着每个 /I 编译器选项指定的路径。
沿着 INCLUDE 环境变量指定的路径。
尖括号形式
预处理器按以下顺序搜索包含文件：
沿着每个 /I 编译器选项指定的路径。
在命令行上进行编译时，沿着 INCLUDE 环境变量指定的路径进行。

Thanks for the great answers, esp. Adam Stelmaszczyk and piCookie, and aib.

Like many programmers, I have used the informal convention of using the "myApp.hpp" form for application specific files, and the <libHeader.hpp> form for library and compiler system files, i.e. files specified in /I and the INCLUDE environment variable, for years thinking that was the standard.

However, the C standard states that the search order is implementation specific, which can make portability complicated. To make matters worse, we use jam, which automagically figures out where the include files are. You can use relative or absolute paths for your include files. i.e.

#include "../../MyProgDir/SourceDir1/someFile.hpp"

Older versions of MSVS required double backslashes (\\), but now that's not required. I don't know when it changed. Just use forward slashes for compatibility with 'nix (Windows will accept that).

If you are really worried about it, use "./myHeader.h" for an include file in the same directory as the source code (my current, very large project has some duplicate include file names scattered about--really a configuration management problem).

Here's the MSDN explanation copied here for your convenience).

Quoted form
The preprocessor searches for include files in this order:
In the same directory as the file that contains the #include statement.
In the directories of the currently opened include files, in the reverse order in which
they were opened. The search begins in the directory of the parent include file and
continues upward through the directories of any grandparent include files.
Along the path that's specified by each /I compiler option.
Along the paths that are specified by the INCLUDE environment variable.
Angle-bracket form
The preprocessor searches for include files in this order:
Along the path that's specified by each /I compiler option.
When compiling occurs on the command line, along the paths that are specified by the INCLUDE environment variable.

回复收藏 0 原文

肩上的翅膀 2024-07-11 10:10:45

至少对于 GCC 版本 <= 3.0，尖括号形式不会在包含文件和包含文件之间生成依赖关系。

因此，如果要生成依赖关系规则（例如使用 GCC -M 选项），则必须对应包含在依赖关系树中的文件使用带引号的形式。

（请参阅http://gcc.gnu.org/onlinedocs/cpp/Initation.html)

回复收藏 0 原文

南七夏 2024-07-11 10:10:45

GCC 文档关于两者之间的区别如下：

使用预处理指令'#include'包含用户和系统头文件。它有两个变体：
<块引用>
#include <文件>
此变体用于系统头文件。它在标准系统目录列表中搜索名为 file 的文件。您可以使用 -I 选项将目录添加到此列表中（请参阅调用）。
#include“文件”
此变体用于您自己的程序的头文件。它首先在包含当前文件的目录中搜索名为 file 的文件，然后在引用目录中搜索，然后在用于的相同目录中搜索。您可以使用 -iquote 选项将目录添加到引用目录列表中。
'#include' 的参数，无论是用引号还是尖括号分隔，其行为都类似于字符串常量，因为无法识别注释，并且不会扩展宏名称。因此，#include指定包含名为 x/*y 的系统头文件。
但是，如果文件中出现反斜杠，它们将被视为普通文本字符，而不是转义字符。不处理任何适合 C 中字符串常量的字符转义序列。因此，#include "x\n\\y" 指定包含三个反斜杠的文件名。（某些系统将 '\' 解释为路径名分隔符。所有这些系统也以相同的方式解释 '/'。仅使用 '/' 是最可移植的。）
如果文件名后面的行有任何内容（注释除外），则为错误。

回复收藏 0 原文

温柔戏命师 2024-07-11 10:10:45

预处理器的确切行为因编译器而异。以下答案适用于 GCC 和其他几个编译器。

#include 告诉编译器在其“includes”目录中搜索标头，例如对于 MinGW，编译器将在 C 中搜索 file.h :\MinGW\include\ 或安装编译器的任何位置。

#include "file" 告诉编译器在当前目录（即源文件所在的目录）中搜索file。

您可以使用 GCC 的 -I 标志来告诉它，当它遇到带尖括号的包含时，它还应该在 -I 之后的目录中搜索标头。 GCC 会将标志后面的目录视为 includes 目录。

例如，如果您自己的目录中有一个名为 myheader.h 的文件，并且您使用标志 < 调用 GCC，则可以说 #include code>-I . （表示它应该在当前目录中搜索包含内容。）

如果没有 -I 标志，您将不得不使用 #include "myheader.h " 以包含该文件，或将 myheader.h 移动到编译器的 include 目录。

回复收藏 0 原文

还在原地等你 2024-07-11 10:10:45

这里的一些很好的答案引用了 C 标准，但忘记了 POSIX 标准，尤其是 c99 (例如C编译器）命令。

根据The Open Group 基本规范第 7 期，

-I 目录
将搜索名称不是绝对路径名的标头的算法更改为先在目录路径名命名的目录中查找，然后再在通常的位置查找。因此，名称用双引号 ( "" ) 括起来的标头应首先在带有 #include 行的文件目录中搜索，然后在 -I< 中命名的目录中搜索。 /strong> 选项，最后放在通常的位置。对于名称包含在尖括号 ( "<>" ) 中的标头，应仅在 -I 选项命名的目录中搜索标头，然后在通常的位置搜索标头。应按指定的顺序搜索-I选项中指定的目录。实现应在单个 c99 命令调用中支持至少十个此选项的实例。

因此，在符合 POSIX 标准的环境中，使用符合 POSIX 标准的 C 编译器，#include "file.h" 可能会首先搜索 ./file.h，其中. 是带有 #include 语句的文件所在的目录，而 #include 可能会搜索首先对于 /usr/include/file.h ，其中 /usr/include 是系统为标头定义的常用位置（似乎没有定义）通过 POSIX）。

回复收藏 0 原文

第七度阳光i 2024-07-11 10:10:45

include 告诉预处理器首先在 -I 目录和预定义目录中搜索，然后在 .c 文件的目录中搜索。 "file" 包含告诉预处理器首先搜索源文件的目录，然后恢复到-I 和预定义。无论如何，所有目的地都会被搜索，只是搜索顺序不同。

2011年标准在“16.2源文件包含”中主要讨论了包含文件。

2 表单的预处理指令
# include; 换行
在一系列实现定义的位置中搜索由唯一标识的标头
<之间的指定序列和> 分隔符，并导致
用标头的全部内容替换该指令。
如何指定位置或识别标题是
实现定义的。
3 表单的预处理指令
# 包含“q-char-sequence”换行符
导致该指令被替换为由所标识的源文件的全部内容
" 分隔符之间的指定序列。指定的源文件是
以实现定义的方式搜索。如果这个搜索是
不支持，或者如果搜索失败，该指令将被重新处理为
如果读到
# include; 换行
具有与原始指令相同的包含序列（包括 > 字符，如果有的话）。

请注意，如果未找到文件，"xxx" 形式将降级为形式。其余的由实现定义。

回复收藏 0 原文

罗罗贝儿 2024-07-11 10:10:45

它确实：

"mypath/myfile" is short for ./mypath/myfile

. 是包含 #include 的文件目录，和/或编译器的当前工作目录，和/或 < code>default_include_paths

和

<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile

如果 ./ 位于中，则没有区别。

如果 mypath/myfile 位于另一个包含目录中，则行为未定义。

It does:

"mypath/myfile" is short for ./mypath/myfile

with . being either the directory of the file where the #include is contained in, and/or the current working directory of the compiler, and/or the default_include_paths

and

<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile

If ./ is in <default_include_paths>, then it doesn't make a difference.

If mypath/myfile is in another include directory, the behavior is undefined.

回复收藏 0 原文

#include<文件名>和 #include<文件名>有什么区别？和#include“文件名”？

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（30）

表格 1 - #include < xxx>

形式 2 - #include "xxx"

Form 1 - #include < xxx >

Form 2 - #include "xxx"

定义：

Definitions:

定义：

Definitions:

关于作者

相关话题

热门标签

推荐作者

qq_FjTq5B

18273202778

WordPress小学生

〃温暖了心ぐ

迷乱花海

niuniu

友情链接

#include<文件名>和 #include<文件名>有什么区别？ 和#include“文件名”？

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（30）

表格 1 - #include < xxx>

形式 2 - #include "xxx"

Form 1 - #include < xxx >

Form 2 - #include "xxx"

定义：

Definitions:

定义：

Definitions:

关于作者

相关话题

热门标签

推荐作者

qq_FjTq5B

18273202778

WordPress小学生

〃温暖了心ぐ

迷乱花海

niuniu

友情链接

#include<文件名>和 #include<文件名>有什么区别？和#include“文件名”？

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。