Por que #include <iostream.h> é ruim?

Eu estava lendo outro tópico em que um cara perguntou sobre livros em C ++ para iniciantes, e um dos programadores que responderam escreveu isso:

Alguns avisos: evite todos os livros que apresentem um "olá mundo" declarando com

#include <iostream.h>

Abri meu livro em C ++ e, com certeza, incluía o cabeçalho iostream como no exemplo acima.

Por que isso é ruim? Que outros indicadores devo ter em mente ao aprender C ++?

Antecedentes: Sou proficiente em C e começarei a aprender C ++ neste próximo semestre.

O cabeçalho iostream.h é um cabeçalho não padrão e não existe em todas as plataformas. De fato, ele não existe no meu sistema (usando o g ++ e o GNU libstdc ++). Portanto, qualquer código que o utilize simplesmente não será compilado no meu sistema.

O iostream.hcabeçalho costumava ser comum antes do C ++ ser padronizado pela primeira vez em 1998. Mas desde que o padrão 98 foi usado, em <iostream>vez de <iostream.h>, o último caiu em desuso (sendo não padrão e tudo) e não é mais suportado em todas as plataformas. O código que o utiliza deve ser considerado código legado não padrão e não é portátil. Os livros que o ensinam devem ser considerados ultrapassados ​​e evitados.

#include <iostream.h>é um sinal de que o livro foi escrito antes do primeiro padrão C ++ em 1998 (o cabeçalho padrão é iostream).

O problema é que o código C ++ mais antigo tende a ser gravado de maneiras que hoje são consideradas más práticas. Em particular,

• O uso de matrizes no estilo C em vez de classes de contêiner como std::stringe std::vector.
• O uso de closefunções explícitas em vez de RAII.

iostream.hnão é a pior coisa que um livro antes de 1998 vai dar errado, mas é provável que seja a primeira coisa que um livro antes de 1998 vai dar errado.

Talvez isso seja um pouco tarde, mas pelo que vale a pena, em uma caixa unix / linux faça ls /usr/{local/,}include/c++/*ou similar, de acordo com seu layout e caminhos. Você pode grepprocurar o cabeçalho em questão, como:

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

Isso envolve uma pesquisa iostream.h, bem como quaisquer outras supercordas.

Ou execute find / -type f -name iostream 2> /dev/null | grep includeou locate iostream | grep include(desde que o banco de dados seja atual; caso contrário, inclua uma chamada para updatedb) - estes, no entanto, também imprimirão inclusões que não são do sistema, portanto, ajuste-o adequadamente. O caminho de inclusão C ++ real é facilmente encontrado com algo como:

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

Equivalentemente no Windows e em outras máquinas. Eu acho que a idéia é clara - como um arquivo iostream.hque não existe no sistema inclui o caminho por padrão por mais tempo, você ainda pode, no entanto, encontrar distribuições legadas do libc ++ com iostream.hum link direto iostreamou cópia dele. Portanto, isso não é uma questão de estilo, mas das circunstâncias. Você pode enviar seu próprio iostream.hprojeto apenas para garantir que ele esteja contido no caminho de inclusão, onde seu compilador procura os <...>cabeçalhos.

Apenas caindo meus 2 centavos. Eu não acho que exista uma correlação entre ".h" e a qualidade de um livro. Esse é um problema menor de sintaxe. Naquela época, era na verdade a sintaxe correta.

É possível ter um ótimo livro com o iostream.h? sim

É possível ter um livro terrível com o iostream? sim

Eu confiaria nas resenhas de usuários on-line (e na minha própria resenha após a leitura) para julgar a qualidade de um livro.