Pourquoi #include <iostream.h> est-il mauvais?

Je lisais un autre fil de discussion où un type a posé des questions sur les livres C ++ pour débutants, et l'un des programmeurs répondant a écrit ceci:

Quelques avertissements: évitez tous les livres qui présentent un "bonjour le monde" déclarant avec

#include <iostream.h>

J'ai ouvert mon livre C ++ et, bien sûr, il incluait l'en-tête iostream comme dans l'exemple ci-dessus.

Pourquoi est-ce mauvais? Quels autres indicateurs dois-je garder à l'esprit lors de l'apprentissage de C ++?

Contexte: Je maîtrise le C et je vais commencer à apprendre le C ++ au cours du prochain semestre.

L'en-tête iostream.h est un en-tête non standard et n'existe pas sur toutes les plateformes. En fait, il n’existe pas sur mon système (avec g ++ et GNU libstdc ++). Ainsi, tout code l’utilisant ne serait tout simplement pas compilé sur mon système.

L' en- iostream.htête utilisé pour être commun avant C ++ a été standardisé en 1998. Mais depuis le 98 norme utilisée au <iostream>lieu de <iostream.h>, celui - ci est tombé en disgrâce (être non-standard et tous) et ne sera plus pris en charge sur toutes les plateformes. Le code qui l'utilise doit être considéré comme un code hérité non standard et n'est pas portable. Les livres qui l'enseignent doivent être considérés comme obsolètes et à éviter.

#include <iostream.h>est un signe que le livre a été écrit avant la première norme C ++ en 1998 (l’en-tête de la norme est iostream).

Le problème est que l'ancien code C ++ a tendance à être écrit d'une manière qui est considérée comme une mauvaise pratique aujourd'hui. En particulier,

• Utilisation de tableaux de style C plutôt que de classes de conteneur telles que std::stringet std::vector.
• L'utilisation de closefonctions explicites plutôt que de RAII.

iostream.hCe n'est pas la pire chose qu'un livre d'avant 1998 se trompera, mais c'est probablement la première chose qu'un livre d'avant 1998 se trompera.

Peut-être que cela arrive un peu tard, mais pour ce que ça vaut, sur une boîte unix / linux, faites-le ls /usr/{local/,}include/c++/*ou quelque chose de similaire, en fonction de votre mise en page et de vos chemins. Vous pourriez vous diriger vers la greprecherche de l'en-tête en question, comme:

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

Cela implique une recherche pour iostream.htoutes les supercordes.

Ou exécutez find / -type f -name iostream 2> /dev/null | grep includeou locate iostream | grep include(à condition que la base de données soit actuelle, sinon ajoutez un appel à updatedb), mais ceux-ci imprimeront également des inclusions qui ne sont pas à l'échelle du système. Veuillez donc effectuer les ajustements appropriés. Le chemin d’inclusion C ++ réel se trouve facilement avec quelque chose comme:

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

De manière équivalente sur Windows et d'autres machines. Je suppose que l’idée est claire: un fichier iostream.hn’existant plus dans le chemin d’inclusion système par défaut, vous pouvez néanmoins trouver des distributions héritées de libc ++ avec iostream.hune liaison logicielle iostreamou en tant que copie. Ce n’est donc pas une question de style mais plutôt de circonstances. Vous pouvez envoyer le vôtre iostream.havec votre projet en vous assurant simplement qu'il est contenu dans le chemin d'inclusion où votre compilateur recherche les en- <...>têtes.

Je laisse tomber mes 2 cents. Je ne pense pas qu'il y ait une corrélation entre ".h" et la qualité d'un livre. Ceci est un problème mineur de syntaxe. À l'époque, c'était en fait le sytnax correct.

Est-il possible d'avoir un bon livre avec iostream.h? Oui

Est-il possible d'avoir un livre terrible avec iostream? Oui

Je me fierais aux avis d’utilisateurs en ligne (et à mes propres commentaires après lecture) pour juger de la qualité d’un livre.