编译器如何知道在何处查找include<stdio.h>?

编译程序构建后,它知道一些查找头文件的标准位置。其中有些独立于编译器的安装位置(如/usr/include、/usr/local/include等),有些则基于编译器的安装位置(对于gcc,在运行configure时由--prefix选项控制)。

像/usr/include这样的位置是众所周知的,并且GCC中内置了该位置的“知识”。像/usr/local/include这样的位置被认为不是完全标准的,并且可以在gcc构建时使用--with-local prefix选项configure进行设置。

也就是说,您可以使用compiler-i命令行选项添加新目录,以便在其中搜索包含文件。当试图包含一个文件时,它将在我在第一段中提到的目录之前查找使用-i标志指定的目录。

操作系统不知道编译器在哪里查找这些文件(或者更准确地说,是预处理器)。它有一组搜索路径,知道在其中查找头,就像命令shell有一组位置,当您键入名称时,它将在其中查找要执行的程序。 The GCC documentation explains 编译器是如何做到的,以及如何更改这些搜索路径的。

文件的位置取决于系统。事实上,文件可能是 precompiled 或者它甚至可能不存在,编译器可能将其作为“内置的”。在我的MacBook上,我看到里面有这样一个文件 /usr/include/c++/4.2.1/iostream 但是你不应该依赖它,它绝对是 坏主意 编辑它。

在Visual Studio中,如果使用IDE,则它位于项目设置中,或者位于 %INCLUDE% 环境变量(如果使用命令行)。

如果您使用的是G++,您可以这样做来查找搜索的包含路径:

touch empty.cpp
g++ -v empty.cpp

我不知道是否有Xcode的等价物。也许这会奏效,因为Xcode是基于gcc的?

您应该避免使用绝对路径包含ING文件。编译器在不同目录中搜索include文件,并从每个目录开始搜索include文件。例如;

#include <boost/tokenizer.hpp>

因为boost根目录包含一个名为“boost”的文件夹,并且该文件夹位于默认包含路径中,或者您执行了类似的操作。

g++ -I$BOOST_ROOT {blah,  blah}

无论是主机系统实际使用什么来表示目录,UNIX分隔符'/'都将以相同的方式工作于所有系统,这是C和C++标准。正如前面提到的,有时候include根本不包含真正的文件。