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

<iostream> vs. <iostream.h> vs. "iostream.h"

提问by BeachRunnerFred

When including a header file in C++, what's the difference between...

在 C++ 中包含头文件时，...

1) including the .h versus not including the .h when wrapping it in < > signs?

1) 将 .h 包含在 < > 符号中时，是包含 .h 还是不包含 .h？

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

2) wrapping the header name in double quotes versus wrapping it in < > signs?

2) 将标题名称用双引号括起来还是用 < > 符号括起来？

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

Thanks in advance!

提前致谢！

回答by Adam Davis

In short:

简而言之：

iostream.his deprecated—it is the original Stroustrup version. iostreamis the version from the standards committee. Generally, compilers point them both to the same thing, but some older compilers won't have the older one. In some odd cases, they will both exist and be different (to support legacy code) and you then must be specific.

iostream.h已弃用——它是原始的 Stroustrup 版本。iostream是标准委员会的版本。通常，编译器将它们指向同一件事，但一些较旧的编译器不会具有较旧的编译器。在一些奇怪的情况下，它们既存在又不同（以支持遗留代码），然后您必须具体。

""versus <>simply means check the local directories for the header before going to the library (in most compilers).

""vs<>只是意味着在进入库之前检查头文件的本地目录（在大多数编译器中）。

回答by Zee JollyRoger

Here is a decent link article.

这是一篇不错的链接文章。

To summarize, the reason given:

总结一下，给出的原因：

The version of the iostream library that the Standards Committee produced was quite a bit different from the CFront implementation. {snip}

To ease transition, the C++ Standards Committee declared that code including the standard C++ headers would use include directives that lack an extension. This allowed compiler vendors to ship the old style C++ library headers with the .h extension and the new style headers without.

标准委员会生成的 iostream 库版本与 CFront 实现有很大不同。{剪}

为了简化转换，C++ 标准委员会宣布包含标准 C++ 头文件的代码将使用缺少扩展的包含指令。这允许编译器供应商提供带有 .h 扩展名的旧式 C++ 库头文件和不带 .h 扩展名的新式头文件。

An advantage of not using the .h version:

不使用 .h 版本的优势：

There are several reasons why new code should be written using the extensionless version of the header files instead of the .h forms. The first is the unpredictability of such code when compiled on modern compilers. As previously mentioned, the result of using the .h headers is implementation specific. And as time goes by, the chance that a given compiler will have the old style library available decreases.

应该使用无扩展版本的头文件而不是 .h 形式编写新代码的原因有很多。首先是这些代码在现代编译器上编译时的不可预测性。如前所述，使用 .h 标头的结果是特定于实现的。随着时间的推移，给定编译器提供旧样式库的机会会减少。

回答by Aron Insinga

As the person on the standards committee (X3J16) who proposed leaving off the .h, my original intent was to settle the debate over .h, .H, .hpp, .hxx, or .h++ file extensions; or a desire by some that there be no implication in the standard that this was the name of a file on disk in order to allow an IDE to pull pre-compiled header information out of someplace internal like a resource file or even the guts of the compiler.

作为标准委员会 (X3J16) 中提议放弃 .h 的人，我的初衷是解决关于 .h、.H、.hpp、.hxx 或 .h++ 文件扩展名的争论；或者某些人希望标准中没有暗示这是磁盘上文件的名称，以便允许 IDE 从内部某个地方（如资源文件甚至是内部文件）中提取预编译的头信息编译器。

While Unix considered the filename to be a single string and did not actually recognize the concept of an extension, DEC operating systems had a tradition of separating the name from the extension, and supplying the "default extension" if it was omitted in particular contexts. That's where I got the idea from of leaving it up to the implementation to use whatever extension the implementation wanted to use, and it allowed the implementation to not even have this a file on disk. (I was DEC's rep. on the committee at the time.)

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

Differentiating between the standard and the pre-standard headers was an added benefit.

区分标准头和预标准头是一个额外的好处。

回答by CesarB

The standard way (and the only one guaranteed to work) is <iostream>. On gcc, <iostream.h> (which might need to be included as <backward/iostream.h>) pulls the relevant declarations to the global namespace (so you do not need the std:: namespace prefix).

标准方法（也是唯一保证有效的方法）是 <iostream>。在 gcc 上，<iostream.h>（可能需要作为 <backward/iostream.h> 包含）将相关声明拉到全局命名空间（因此您不需要 std:: 命名空间前缀）。

"iostream.h" would try first from the directory with your source code, since "" is meant for headers from your project. <> should always be used for system headers, and "" for your own headers.

"iostream.h" 将首先从您的源代码目录中尝试，因为 "" 表示您项目中的标头。<> 应始终用于系统标头，而 "" 应始终用于您自己的标头。

回答by Uri

Typically <> is used for system or standard library files whereas "" is used for project files. I would not be surprised if your compiler searches locally and when it cannot find it it defaults to the standard library version.

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

As for the .h, I don't think that it actually matters if you use C. In C++, I remember vaguely that there was a newer version and an older version and that without the h it was supposed to be the new version, but I'm not even sure the old version still exists.

至于.h，我认为如果你使用C实际上并不重要。在C++中，我依稀记得有一个新版本和一个旧版本，如果没有h，它应该是新版本，但我什至不确定旧版本是否仍然存在。

回答by Aron Insinga

Regarding the names of the standard C++ header files, in the early days (first 2 years) of X3J16, we faced an argument over what the extension should be on the standard C++ header files. In use at the time by various vendors (and influenced by constraints that some operating systems placed on file names) I believe there were .h, .H, .h++, .hpp, .HXX, and possibly others. In a library group meeting I suggested that we leave the extension off, and leave it up to the implementation to supply a default file extension of its choosing if there was none in the include line, or use the name as a key in a database of pre-compiled header files if desired. [While Unix-like systems treat the filename and 'extension' as a single string, I was representing DEC on the committee, and many DEC operating systems stored the extension in the directory as a separate field from the name. So DEC operating systems had a strong tradition of applying a default extension based on what program was accessing the file for what purpose. Telling an assembler 'X,Y=Z' might result in reading input file Z.MAC (macro) and writing output files X.OBJ and Y.LST.] Anyway, it avoided a long, no-win debate, so the group went along with it, and Andy Koenig presented the group's conclusions on this (among others) to the entire committee which accepted it. I find it somewhat amusing that implementations missed the whole point that they could apply a default extension of their choice (which I would think would be useful to editors and other tools) and just left the extension off of the file name.

关于标准 C++ 头文件的名称，在 X3J16 的早期（前两年），我们面临着关于标准 C++ 头文件的扩展名应该是什么的争论。当时被各种供应商使用（并且受到某些操作系统对文件名的限制）我相信有 .h、.H、.h++、.hpp、.HXX 和其他可能的。在一次图书馆小组会议上，我建议我们不使用扩展名，如果包含行中没有扩展名，则由实现提供其选择的默认文件扩展名，或者使用名称作为数据库中的键如果需要，预编译的头文件。[虽然类 Unix 系统将文件名和“扩展名”视为单个字符串，但我在委员会中代表 DEC，并且许多 DEC 操作系统将扩展名作为与名称分开的字段存储在目录中。因此，DEC 操作系统有一个强大的传统，即根据什么程序出于什么目的访问文件来应用默认扩展名。告诉汇编器 'X,Y=Z' 可能会导致读取输入文件 Z.MAC（宏）并写入输出文件 X.OBJ 和 Y.LST。] 不管怎样，它避免了一场长时间的、没有赢的争论，所以小组随之而来，安迪·科尼格 (Andy Koenig) 向接受它的整个委员会提交了小组对此的结论（以及其他结论）。我觉得有点有趣的是，实现忽略了他们可以应用他们选择的默认扩展名（我认为这对编辑器和其他工具有用）的全部要点，而只是将扩展名从文件名中删除。因此，DEC 操作系统有一个强大的传统，即根据什么程序出于什么目的访问文件来应用默认扩展名。告诉汇编器 'X,Y=Z' 可能会导致读取输入文件 Z.MAC（宏）并写入输出文件 X.OBJ 和 Y.LST。] 不管怎样，它避免了一场长时间的、没有赢的争论，所以小组随之而来，安迪·科尼格 (Andy Koenig) 向接受它的整个委员会提交了小组对此的结论（以及其他结论）。我觉得有点有趣的是，实现忽略了他们可以应用他们选择的默认扩展名（我认为这对编辑器和其他工具有用）的全部要点，而只是将扩展名从文件名中删除。因此，DEC 操作系统有一个强大的传统，即根据什么程序出于什么目的访问文件来应用默认扩展名。告诉汇编器 'X,Y=Z' 可能会导致读取输入文件 Z.MAC（宏）并写入输出文件 X.OBJ 和 Y.LST。] 不管怎样，它避免了一场长时间的、没有赢的争论，所以小组随之而来，安迪·科尼格 (Andy Koenig) 向接受它的整个委员会提交了小组对此的结论（以及其他结论）。我觉得有点有趣的是，实现忽略了他们可以应用他们选择的默认扩展名（我认为这对编辑器和其他工具有用）的全部要点，而只是将扩展名从文件名中删除。告诉汇编器 'X,Y=Z' 可能会导致读取输入文件 Z.MAC（宏）并写入输出文件 X.OBJ 和 Y.LST。] 不管怎样，它避免了一场长时间的、没有赢的争论，所以小组随之而来，安迪·科尼格 (Andy Koenig) 向接受它的整个委员会提交了小组对此的结论（以及其他结论）。我觉得有点有趣的是，实现忽略了他们可以应用他们选择的默认扩展名（我认为这对编辑器和其他工具有用）的全部要点，而只是将扩展名从文件名中删除。告诉汇编器 'X,Y=Z' 可能会导致读取输入文件 Z.MAC（宏）并写入输出文件 X.OBJ 和 Y.LST。] 不管怎样，它避免了一场长时间的、没有赢的争论，所以小组随之而来，安迪·科尼格 (Andy Koenig) 向接受它的整个委员会提交了小组对此的结论（以及其他结论）。我觉得有点有趣的是，实现忽略了他们可以应用他们选择的默认扩展名（我认为这对编辑器和其他工具有用）的全部要点，而只是将扩展名从文件名中删除。就此（以及其他）向接受它的整个委员会作出结论。我觉得有点有趣的是，实现忽略了他们可以应用他们选择的默认扩展名（我认为这对编辑器和其他工具有用）的全部要点，而只是将扩展名从文件名中删除。就此（除其他外）向接受它的整个委员会作出结论。我觉得有点有趣的是，实现忽略了他们可以应用他们选择的默认扩展名（我认为这对编辑器和其他工具有用）的全部要点，而只是将扩展名从文件名中删除。

回答by Ferruccio

These are really two different questions.

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

• The difference between the .h and extensionless headers with the same name is historical. The ones with the .h extension are from the original C++ standard which did not have some modern features such as namespaces and templates. It was simpler for the new standard to put that same functionality in new header files to be able to use these new features and keep the old (.h) files for backward compatibility of legacy code.

• The difference between the #include <...> and #include "..." format is the order in which the compiler looks for files. This is generally implementation dependent, but the idea is that the <> format looks in system include directories first, while "" looks in the same directory as the source file that #included it first.

• .h 和同名无扩展标头之间的区别是历史性的。带有 .h 扩展名的那些来自原始的 C++ 标准，它没有一些现代特性，如命名空间和模板。新标准将相同的功能放在新的头文件中更简单，以便能够使用这些新功能并保留旧的 (.h) 文件以实现遗留代码的向后兼容性。

• #include <...> 和#include "..." 格式之间的区别在于编译器查找文件的顺序。这通常取决于实现，但其想法是 <> 格式首先在系统包含目录中查找，而 "" 在与 #include 它首先包含它的源文件相同的目录中查找。

回答by yogman

The simple answer to the first answer is that iostream.h doesn't exist, at least in the GCC implementation. If you're on *nix, type

第一个答案的简单答案是 iostream.h 不存在，至少在 GCC 实现中是这样。如果您使用的是 *nix，请输入

% locate iostream.h
/usr/include/c++/3.4.3/backward/iostream.h

% 找到 iostream.h
/usr/include/c++/3.4.3/backward/iostream.h

and

和

% locate iostream
/usr/include/c++/3.4.3/iostream
/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

As Zee's article says, iostream.h is for backward compatibility.

正如 Zee 的文章所说， iostream.h 是为了向后兼容。