在 C++ 中包含头文件时，和...有什么区别
1) 在 符号中包含 .h 与不包含 .h？
#include <iostream> vs. #include <iostream.h>
2) 将标题名称用双引号括起来还是用 符号括起来？
#include <iostream.h> vs. #include "iostream.h"
提前致谢！
【问题讨论】：
简而言之：
iostream.h 已弃用——它是原始的 Stroustrup 版本。 iostream 是标准委员会的版本。通常，编译器将它们都指向同一事物，但一些较旧的编译器不会有较旧的编译器。在某些奇怪的情况下，它们既存在又不同（以支持遗留代码），然后您必须具体。
"" 与 <> 只是意味着在进入库之前检查本地目录中的标头（在大多数编译器中）。
【讨论】：
这是一个不错的链接article.
总结一下，给出的原因：
标准委员会制定的 iostream 库版本 生产的与 CFront 实现有很大不同。 {snip}
为了简化过渡，C++ 标准委员会宣布代码 包含标准 C++ 头文件将使用包含指令 缺少扩展名。这允许编译器供应商发布旧样式 带有 .h 扩展名的 C++ 库头文件和新样式头文件 没有。
不使用 .h 版本的好处：
有几个原因应该使用 头文件的无扩展名版本，而不是 .h 形式。这 首先是在现代编译时此类代码的不可预测性 编译器。如前所述，使用 .h 标头的结果 是特定于实现的。随着时间的推移，一个机会 给定的编译器将减少旧样式库的可用。
【讨论】：
作为标准委员会 (X3J16) 中提议放弃 .h 的人，我的初衷是解决关于 .h、.H、.hpp、.hxx 或 .h++ 文件扩展名的争论；或者某些人希望标准中没有暗示这是磁盘上文件的名称，以便允许 IDE 将预编译的头信息从内部某个地方（如资源文件）甚至是内部文件中提取出来编译器。
虽然 Unix 认为文件名是单个字符串并且实际上并没有识别扩展名的概念，但 DEC 操作系统有将名称与扩展名分开的传统，如果在特定的上下文。这就是我想到将它留给实现使用实现想要使用的任何扩展的想法的地方，它允许实现甚至没有这个文件在磁盘上。 （当时我是委员会的 DEC 代表。）
区分标准头和准标准头是一个额外的好处。
【讨论】：
#include<iostream.h>在我们的程序中包含了一个名为iostream.h的特定文件，而#include<iostream>只是保证所有属于iostream 库包含在我们的程序中。我说的对吗？
标准方式（也是唯一保证有效的方式）是
"iostream.h" 将首先从包含您的源代码的目录中尝试，因为 "" 用于您项目的标头。 应始终用于系统标头，而 "" 应始终用于您自己的标头。
【讨论】：
通常 用于系统或标准库文件，而 "" 用于项目文件。如果您的编译器在本地搜索并且找不到它，我不会感到惊讶，它默认为标准库版本。
至于 .h，我认为如果您使用 C，这实际上并不重要。 在 C++ 中，我依稀记得有一个新版本和一个旧版本，没有 h 应该是新版本，但我什至不确定旧版本是否仍然存在。
【讨论】：
第一个答案的简单答案是 iostream.h 不存在，至少在 GCC 实现中是这样。如果您在 *nix 上，请输入
% 定位 iostream.h
/usr/include/c++/3.4.3/backward/iostream.h
和
% 定位 iostream
/usr/include/c++/3.4.3/iostream
/usr/include/c++/3.4.3/backward/iostream.h
正如 Zee 的文章所说，iostream.h 是为了向后兼容。
【讨论】：
这确实是两个不同的问题。
.h 和 具有相同的无扩展标题 名字是历史的。那些与 .h 扩展名来自 没有的原始 C++ 标准 具有一些现代功能，例如 命名空间和模板。它是 新标准更简单 新功能中的相同功能 头文件能够使用这些 新功能并保留旧功能 (.h) 向后兼容的文件 遗留代码。
#include 之间的区别 <...> 和 #include "..." 格式为 编译器的顺序 寻找文件。这一般是 实施依赖，但 想法是 格式看起来 系统首先包含目录， 而“”在同一目录中查找 作为#included它的源文件 首先。
【讨论】：
关于标准 C++ 头文件的名称，在 X3J16 的早期（前 2 年），我们遇到了关于标准 C++ 头文件的扩展名应该是什么的争论。当时被各种供应商使用（并且受到某些操作系统对文件名的限制的影响）我相信有.h、.H、.h++、.hpp、.HXX，可能还有其他。在图书馆小组会议上，我建议我们关闭扩展名，并让实现提供默认文件扩展名（如果包含行中没有），或者使用名称作为数据库中的键如果需要，预编译头文件。 [虽然类 Unix 系统将文件名和“扩展名”视为单个字符串，但我在委员会中代表 DEC，许多 DEC 操作系统将扩展名作为与名称分开的字段存储在目录中。因此，DEC 操作系统有一个强大的传统，即根据什么程序出于什么目的访问文件来应用默认扩展名。告诉汇编程序“X,Y=Z”可能会导致读取输入文件 Z.MAC（宏）并写入输出文件 X.OBJ 和 Y.LST。] 无论如何，它避免了一场长期的、没有胜利的辩论，所以小组同意它，安迪·科尼格（Andy Koenig）将小组对此（以及其他）的结论提交给接受它的整个委员会。我觉得有些有趣的是，实现忽略了他们可以应用他们选择的默认扩展名的全部要点（我认为这对编辑器和其他工具很有用）并且只是将扩展名从文件名中去掉。
【讨论】：