C++ 编译器如何知道在哪里可以找到#include <stdio.h>？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1899373/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How do compilers know where to find #include <stdio.h>?
提问by Brock Woolf
I am wondering how compilers on Mac OS X, Windows and Linux know where to find the C header files.
我想知道 Mac OS X、Windows 和 Linux 上的编译器如何知道在哪里可以找到 C 头文件。
Specifically I am wondering how it knows where to find the #include with the <>brackets.
具体来说，我想知道它如何知道在哪里可以找到带<>括号的 #include 。
#include "/Users/Brock/Desktop/Myfile.h" // absolute reference
#include <stdio.h> // system relative reference?
I assume there is a text file on the system that it consults. How does it know where to look for the headers? Is it possible to modify this file, if so where does this file reside on the operating system?
我假设它查询的系统上有一个文本文件。它如何知道在哪里寻找标题？是否可以修改此文件，如果可以，此文件在操作系统上的什么位置？
采纳答案by R Samuel Klatchko
When the compiler is built, it knows about a few standard locations to look for header file. Some of them are independent of where the compiler is installed (such as /usr/include, /usr/local/include, etc.) and some of the are based on where the compiler is installed (which for gcc, is controlled by the --prefix option when running configure).
当编译器被构建时，它知道一些标准位置来查找头文件。其中一些与编译器的安装位置无关（例如 /usr/include、/usr/local/include 等），而另一些则基于编译器的安装位置（对于 gcc，由--prefix 运行配置时的选项）。
Locations like /usr/include are well known and 'knowledge' of that location is built into gcc. Locations like /usr/local/include is not considered completely standard and can be set when gcc is built with the --with-local-prefix option of configure.
像 /usr/include 这样的位置是众所周知的，并且该位置的“知识”已内置到 gcc 中。像 /usr/local/include 这样的位置不被认为是完全标准的，可以在 gcc 使用 configure 的 --with-local-prefix 选项构建时进行设置。
That said, you can add new directories for where to search for include files using the compiler -I command line option. When trying to include a file, it will look in the directories specified with the -I flag before the directories I talked about in the first paragraph.
也就是说，您可以使用编译器 -I 命令行选项为搜索包含文件的位置添加新目录。当试图包含一个文件时，它会在我在第一段中提到的目录之前查找用 -I 标志指定的目录。
回答by Chuck
The OS does not know where look for these files — the compiler does (or more accurately, the preprocessor). It has a set of search paths where it knows to look for headers, much like your command shell has a set of places where it will look for programs to execute when you type in a name. The GCC documentation explainshow that compiler does it and how these search paths can be changed.
操作系统不知道在哪里寻找这些文件——编译器知道（或者更准确地说，预处理器）。它有一组搜索路径，它知道在其中查找标题，就像您的命令外壳程序有一组位置一样，它会在您键入名称时查找要执行的程序。GCC 文档解释了该编译器如何执行此操作以及如何更改这些搜索路径。
回答by Alok Singhal
The location of the file is system dependent. Indeed, the file might be precompiled, or it may not even exist—the compiler may have it as a 'built-in'. On my macbook, I see that there's such a file in /usr/include/c++/4.2.1/iostream, but you shouldn't rely on it, and it's definitely a bad ideato edit it.
文件的位置取决于系统。事实上，该文件可能是预编译的，或者它甚至可能不存在——编译器可能将其作为“内置”。在我的 macbook 上，我看到 中有这样一个文件/usr/include/c++/4.2.1/iostream，但你不应该依赖它，编辑它绝对是一个坏主意。
回答by Alex Budovski
In Visual Studio, it's either in the project settings if you use the IDE, or in the %INCLUDE%environment variable if you use the command line.
在 Visual Studio 中，如果使用 IDE，则它位于项目设置中，%INCLUDE%如果使用命令行，则位于环境变量中。
回答by Chris Huang-Leaver
You should avoid #include-ing files using absolute paths. The compiler searches for the include files in various directories and includes files, starting from each directory. For example;
您应该避免使用绝对路径的 #include-ing 文件。编译器在各个目录中搜索包含文件并从每个目录开始包含文件。例如;
#include <boost/tokenizer.hpp>
Works because the boost root directory contains a folder called 'boost' and that folder is either in your default include path or you did something like.
之所以有效，是因为 boost 根目录包含一个名为“boost”的文件夹，并且该文件夹位于您的默认包含路径中，或者您执行了类似的操作。
g++ -I$BOOST_ROOT {blah, blah}
It is C and C++ standard that the UNIX separator '/' will work the same way for all systems, regardless of what the host system actually uses to denote directories. As others of mentioned, occasionally #include doesn't actually include a real file at all.
无论主机系统实际使用什么来表示目录，UNIX 分隔符“/”对所有系统的工作方式都是相同的，这是 C 和 C++ 标准。正如其他人提到的，偶尔 #include 实际上根本不包含真实文件。
回答by Dan
If you were using g++, you could do something like this to find out what include paths were searched:
如果您使用的是 g++，您可以执行以下操作来找出搜索的包含路径：
touch empty.cpp
g++ -v empty.cpp
I don't know if there's an equivalent for Xcode. Maybe that will work since Xcode is based on GCC?
我不知道 Xcode 是否有等价物。也许这会起作用，因为 Xcode 基于 GCC？
