出于这个问题的目的，我只对标准兼容的C ++感兴趣，而不是对C或C ++ 0x感兴趣，而不是任何特定于实现的细节。
Questions不时出现#include ""和#include <>之间的差异。这个论点通常归结为两个不同之处：
#include <>用于“标题”，而#include ""用于“源文件”。以下是相关参考：
ISO / IEC 14882：2003（E）
16.2源文件包含[cpp.include]
1 #include指令应标识可由实现处理的头文件或源文件。
2 表单的预处理指令
搜索一系列实现定义的位置，以获得由＆lt;之间的指定序列唯一标识的标题。和＆gt;分隔符，并导致该标题的整个内容替换该指令。如何指定场所或标识的标题是实现定义的。# include < h-char-sequence > new-line
3 表单的预处理指令
导致由“分隔符”之间的指定序列标识的源文件的全部内容替换该伪指令。以实现定义的方式搜索命名的源文件。如果此搜索不是支持，或者如果搜索失败，指令将被重新处理，就像它读取一样# include "q-char-sequence" new-line使用原始指令中相同的包含序列（包括>字符，如果有的话）。# include < h-char-sequence > new-line
（上面引用的重点是我的。）这种差异的含义似乎是标准打算区分“标题”和“源文件”，但文档中没有任何一个定义这些术语或他们之间的区别。
其他几个地方甚至还提到了标题或源文件。一些：
158）标题不一定是源文件，标题名称中分隔的序列也不一定是有效的源文件名（16.2）。
似乎暗示标题可能不会驻留在文件系统中，但也不会说源文件也存在。
2词汇约定[lex]
1 程序文本保存在本国际标准中称为源文件的单元中。通过预处理指令
#include将源文件与所有头文件（17.4.1.2）和包含的源文件（16.2）一起，减少任何条件包含（16.1）预处理指令跳过的任何源代码行，称为翻译单位。 [注意：C + +程序不需要同时翻译。 ]
这是我能找到的最接近定义的内容，它似乎暗示标题不是“程序的文本”。但是如果你#include标题，它不会成为程序文本的一部分吗？这有点误导。
那么什么是标题？什么是源文件？
答案 0 :(得分：8)
我的阅读是使用<>尖括号包含的标准标题不一定是文件系统上的实际文件;例如一个实现可以自由地启用一组“内置”操作，当它看到iostream时提供#include <iostream>的功能。
另一方面，#include "xxx.h"中包含的“源文件”应该是驻留在文件系统上的文字文件，并以某种依赖于实现的方式进行搜索。
修改：为了回答您的具体问题，我认为“标题”仅限于标准中指定的#include能力设施：iostream，vector和朋友---或者通过实施作为标准的扩展。 “源文件”可以是程序员可以编写或使用的任何非标准工具（如.h文件等）。
答案 1 :(得分：4)
这不是说头文件可以作为源文件实现，但又可能没有？至于“什么是源文件”，鉴于“文件”的实现方式很多，标准似乎非常明智，不要拼写出来。
答案 2 :(得分：2)
标准头文件（字符串，iostream）不一定必须是包含这些名称的文件，甚至根本不是文件。只要你说
#include <iostream>
某个声明列表进入范围，标准得到满足。究竟是怎么产生的是一个实现细节。 （在编写标准时，DOS只能处理8.3文件名，但有些标准标题名称比这长）
答案 3 :(得分：2)
正如您的引言所说：标题是使用<>包含的内容，源文件是正在编译的文件，或使用""包含的内容。确切地说，这些内容来自哪些，以及哪些非标准头可用，取决于实现。如果包含标准标头，则所有标准指定都是定义的。
按照惯例，标题通常是系统范围的东西，源文件通常是项目的本地（对于项目的某些定义），但标准明智地不会陷入与项目组织有关的任何事情;它只是给出了与这些约定兼容的非常一般的定义，将细节留给了实现和/或用户。
几乎所有的标准都是经过预处理后对程序进行处理，此时没有源文件或标题，只有你的上一个引号定义的翻译单元。
答案 4 :(得分：0)
嗯...
我随意的理解是＆lt;＆gt;之间的区别包括和“”包括从c继承而且（虽然没有由标准定义）事实上意思是＆lt;＆gt;系统和编译器提供的标题的搜索路径和“”也搜索本地和用户指定的路径。
上面的定义在某种意义上似乎与该用法一致，但是限制了“头”用于由用户提供的编译器或系统独占提供的内容，即使它们是有传统的“界面进入标题”形式。
无论如何，非常有趣。