为什么#include <iostream.h>不好？

我正在阅读另一个线程，一个人向初学者询问有关C ++的书籍，一个回答的程序员写道：

警告：请避免所有带有“ hello world”字样的书都标明

#include <iostream.h>

我打开了我的C ++书，并确定它像上面的示例一样包含iostream标头。

为什么这么糟？学习C ++时，我还应牢记其他哪些指针？

背景：我精通C语言，下学期将开始学习C ++。

头iostream.h是非标准头，并非在所有平台上都存在。事实上，它在我的系统上不存在（使用g ++和GNU libstdc ++）。因此，任何使用它的代码都将无法在我的系统上编译。

在iostream.h使用的头是共同的前C ++是在1998年首先标准化但由于所使用的98标准<iostream>的代替<iostream.h>，后者已经失宠的（即非标和全部），并且不再所有平台都支持。使用该代码的代码应被视为非标准旧代码，并且不可移植。教它的书应该被认为是过时的，应避免使用。

#include <iostream.h>表示这本书是在1998年第一个C ++标准之前编写的（标准标头是iostream）。

问题在于，较旧的C ++代码倾向于以当今被认为是不好的做法来编写。尤其是，

• 使用C样式的数组，而不是像std::string和这样的容器类std::vector。
• 使用显式close函数而不是RAII。

iostream.h1998年前的一本书会出错不是最坏的事情，但1998年前的一本书会出错是第一件事。

也许这有点晚了，但是ls /usr/{local/,}include/c++/*根据您的布局和路径，在unix / linux上可以做什么或类似的价钱。您可以通过管道grep查找有问题的标题，例如：

ls /usr/{local/,}include/c++/* | grep iostream 

这需要查找iostream.h以及其他任何超字符串。

或运行find / -type f -name iostream 2> /dev/null | grep include或locate iostream | grep include（如果数据库是当前数据库，否则以调用为前缀updatedb）-但是，它们还将打印非系统范围内的包含文件，因此请进行适当调整。实际的C ++包含路径很容易找到，例如：

g++ -v 2>&1| sed -rn 's/.+gxx-include[^=]+=([^ ]+).+/\1/p' # adjust iff empty

等效于Windows和其他计算机。我想这个主意很明确- iostream.h默认情况下，系统中不再存在的此类文件不再包含默认路径，但是您仍然可以找到带有iostream.h软链接iostream或作为其副本的旧版libc ++发行版。因此，这不是风格问题，而是环境问题。您可以iostream.h随项目一起提供您自己的项目，只需确保它包含在编译器查找<...>标头的包含路径中即可。

只是丢下我的2美分。我认为“ .h”与书本质量之间没有关联。这是一个较小的语法问题。过去，它实际上是正确的语法。

iostream.h是否可以有一本好书？是

iostream可能会带来一本糟糕的书吗？是

我将依靠在线用户评论（以及阅读后的我自己的评论）来判断一本书的质量。