<iostream>与<iostream.h>与“iostream.h”

Question

当包括C++头文件，有什么区别...

1），包括.H与在<包装时，它不包括.H >标志？

#include <iostream> vs. #include <iostream.h> 

2）包裹在双引号中的头名与在<>标志包装呢？

#include <iostream.h> vs. #include "iostream.h" 

在此先感谢！

Answer 1

简而言之：

iostream.h已经过时 - 它是原始Stroustrup的版本，iostream都是从标准委员会的版本。通常，编译器将它们指向相同的东西，但是一些较老的编译器不会有较旧的编译器。在一些奇怪的情况下，它们都存在并且不同（以支持遗留代码），然后您必须具体。

“”与<>简单的说就是在去库之前（在大多数编译器中）检查头的本地目录。

- 亚当

Answer 2

这里是一个体面的链接article.

总结，给出的理由：

iostream库所产生的标准委员会 是从CFRONT实现相当多的不同的版本。 {}剪断

为了缓解转型期，C++标准委员会宣布，代码 包括标准C++头将使用include指令是 没有扩展名。这允许编译器供应商在没有的情况下将旧版本 带有.h扩展名的C++库标头和新的样式标头 。

不使用的.h版本的优点：

有几个原因，新代码应该使用头文件，而不是.H形式的扩展名 版本被写入。 首先是编译现代 编译器时此类代码的不可预测性。如前所述，使用.h头文件 的结果是特定于实现的。随着时间的推移，给定编译器的机会将会减少旧的样式库。

Answer 3

通常<>用于系统或标准库文件，而“”用于项目文件。如果你的编译器在本地搜索，并且它无法找到它，我不会感到惊讶，它默认为标准库版本。

至于.h，如果你使用C，我认为它并不重要。在C++中，我隐约记得有一个更新的版本和更老的版本，并且没有h成为新版本，但我甚至不确定旧版本仍然存在。

Answer 4

的标准方式（以及仅一个保证工作）是<的iostream >。在gcc上，<iostream.h>（可能需要包含为<backward/iostream.h>）将相关声明提取到全局名称空间（因此您不需要std ::名称空间前缀）。

“iostream.h”会首先从源代码中检索目录，因为“”是指您的项目的头文件。 < >应该始终用于系统标题，“”用于您自己的标题。

Answer 5

第一个答案的简单答案是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是为了向后兼容。

Answer 6

这些确实是两个不同的问题。

• 具有相同名称 h和 扩展名头之间的差异是历史的。带有 .h扩展名的是 原始C++标准，它没有 具有一些现代功能，如 名称空间和模板。这是 简单的新标准把 ，在新 头文件相同的功能，以便能够使用这些 新功能，并保持旧的（.h）中 文件的 遗留代码的向后兼容性。

• 中的#include之间的差异 < ...>和＃包括“...”格式是 在编译器 查找文件的顺序。这通常是 依赖于实现，但 想法是<>格式看起来 系统包含目录第一， 而“”看在同一个目录 为执行#included它 第一源文件。

Answer 7

由于标准委员会（X3J16）谁提出离开关.H的人，我的初衷是解决了.H，.H，.HPP，.HXX，或.H ++文件辩论扩展;或者一些人希望标准中没有暗示这是磁盘上文件的名称，以便IDE能够将预编译的头信息从内部的某个位置（如资源文件）或甚至是内部的编译器。

尽管Unix认为文件名是单个字符串，并且实际上并不能识别扩展的概念，但DEC操作系统有一个传统，即将名称与扩展名分开，如果省略，则提供“默认扩展名”在特定情况下。这就是我将这个想法留给实现来使用实现想要使用的任何扩展，并且它允许实现甚至不在磁盘上存在这个文件。 （当时我是DEC委员会的代表）。

区分标准标题和标准标题是另一个好处。