感谢您的回答，特别是Adam Stelmaszczyk和piCookie，以及aib。

与许多程序员一样，多年来，我一直使用“myApp.hpp”格式作为应用程序特定文件，使用<libHeader.hpp>格式作为库和编译器系统文件（即/I和INCLUDE环境变量中指定的文件）的非正式约定，认为这是标准。

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

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

旧版本的MSVS需要双反斜杠（\\），但现在不需要了。我不知道什么时候变了。为了与'nix兼容，只需使用正斜杠（Windows将接受这一点）。

如果您真的担心这个问题，请使用“./myHeader.h”作为源代码所在目录中的包含文件（我当前的大型项目中有一些重复的包含文件名--这确实是一个配置管理问题）。

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

引用的表单预处理器按以下顺序搜索包含文件：在与包含#include语句的文件相同的目录中。在当前打开的include文件的目录中，按以下相反顺序他们被打开了。搜索从父包含文件的目录开始继续向上通过任何祖父母包含文件的目录。沿着每个/I编译器选项指定的路径。沿着INCLUDE环境变量指定的路径。角钢支架形式预处理器按以下顺序搜索包含文件：沿着每个/I编译器选项指定的路径。在命令行上进行编译时，沿着INCLUDE环境变量指定的路径进行编译。

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

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

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

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

这里的一些好答案引用了C标准，但忘记了POSIX标准，特别是c99（例如C编译器）命令的特定行为。

根据开放组基础规范第7版，

-I目录更改搜索名称不是绝对路径名的标头的算法，以便在查找通常位置之前先查找由目录路径名命名的目录。因此，名称用双引号（“”）括起来的头应首先在文件的目录中搜索#include行，然后在-I选项中命名的目录中，最后在通常的位置搜索。对于名称用尖括号（“<>”）括起来的标题，只能在-I选项中命名的目录中搜索标题，然后在通常的位置搜索标题。应按照指定的顺序搜索-I选项中命名的目录。实现应在单个c99命令调用中支持至少十个此选项的实例。

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

#include <file> 

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

#include "file" 

在编译文件的当前目录中包含文件。双引号还可以指定到其他位置的完整文件路径。

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

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

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

您可以使用GCC的-I标志告诉它，当它遇到带有尖括号的include时，它还应该在-I之后的目录中搜索标头。GCC将把标志后面的目录当作includes目录。

例如，如果您在自己的目录中有一个名为myheader.h的文件，那么如果您使用标志-I调用GCC，可以说#include<myheader.h>。（表示应搜索当前目录中的includes。）

如果没有-I标志，则必须使用#include“myheader.h”来包含文件，或将myheader.h移动到编译器的include目录。