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

47

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.

— Daniel Scocco
source

3

Un autre pointeur connexe consiste à inclure cstdio, non stdio.h(le dernier est obsolète).

— Anton Golov

7

@AntonGolov Les opinions diffèrent. De nombreux experts préfèrent <stdio.h> car il n'y a pas de raison technique pour laquelle <cstdio> devrait être préféré.

— Sjoerd

2

@Sjoerd Le fait <cstdio>de fournir les noms en namespace stdest une raison suffisante pour que je le préfère. Je sais que cela pourrait aussi les fournir dans l’espace de noms global, tout comme <stdio.h> pourrait les fournir dans namespace std. C'est également une question de cohérence si vous prenez l'habitude de toujours utiliser les en- <c…>têtes. Et pour certains en-têtes, vous le souhaiterez vraiment car ils améliorent l'interface C avec des surcharges de fonctions supplémentaires, par exemple.

— 5gon12eder

58

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.

— sepp2k
source

14

Je ne voudrais pas éviter un livre directement à cause d'un problème trivial de syntaxe de pré-processeur. Ce pourrait être un excellent livre alors qu'un livre terrible pourrait utiliser la syntaxe moderne.

— Seigneur Tydus

21

@ Lord Tydus Le fait qu'un livre antérieur à 98 puisse être un excellent livre n'annule pas le fait que statistiquement, il serait préférable d'éviter les livres antérieurs à 98.

— Mike Nakis

12

@ LordTydus: Totalement en désaccord. Le style et l’utilisation du C ++ n’étant pas les mêmes que dans 98, il ne s’agit pas uniquement de résoudre des problèmes de syntaxe.

— Martin York

7

@LordTydus Si l'ancienne syntaxe est simple et ne compile simplement pas sur des compilateurs modernes, vous aurez du mal à utiliser un livre qui enseigne l'ancienne syntaxe. Notez que tout livre qui enseigne l'utilisation de iostream.h n'enseigne presque certainement pas, par exemple, les espaces de noms. Ainsi, même après avoir remplacé iostream.h par iostream, votre code ne fonctionnera pas. Si vous devez google ou demander de l'aide sur SO chaque fois que vous voulez compiler un exemple à partir du livre, ce n'est pas un moyen très efficace d'apprendre le C ++.

— sepp2k

3

@ LordTydus: En général, j'ai constaté que les livres qui utilisent des en-têtes comme celui-ci ont également tendance à utiliser de mauvaises pratiques et sont entachés d'erreurs. Je me suis mis à collectionner de tels livres simplement pour les empêcher de circuler.

— Greyfade

55

#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.

— dan04
source

14

Cloué avec votre dernier paragraphe.

— Courses de légèreté avec Monica

1

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.

— Nicolas
source

1

Très pratique mais ne répond pas vraiment au vrai point fondamental.

— Courses de légèreté avec Monica

-1

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.

— Seigneur Tydus
source

3

Le problème est, êtes-vous sûr de vouloir un livre "de retour dans la journée"?

— Hugomg

5

Lisp est-il obsolète car il date de 1958? Nous utilisons le travail de Pythagore dans tous les systèmes de missiles modernes, même si le calcul est vieux de milliers d'années. Dans le marché du livre C ++ actuel, les livres ".h" pourraient bien être terribles. Mais c’est une qualité de publication, pas un problème ".h". ".h" n'est même pas une logique de programmation, c'est pour le préprocesseur.

— Seigneur Tydus

4

mais quelqu'un qui apprendra la langue pour la première fois saura-t-il que le livre leur dit quelque chose qui ne va pas? Combien de temps et de frustration vont-ils parcourir avant de découvrir que le ".h" est maintenant incorrect? Et de combien d'autres façons le livre est-il périmé?

— Chris Pitman

23

Le problème est que l'utilisation du C ++ a considérablement changé depuis la rédaction de ces livres. La façon dont vous pensez et utilisez le C ++ n’est pas la même chose que ce que ces livres présenteront, car ils ne disposent d’aucun des équipements offerts par le C ++ moderne. En conséquence, vous enseignerez vous-même le C avec des cours autres que le C ++.

— Martin York

3

@ George: ennuyeux. Qu'en est-il d'ACRE. C avancé sur le Ritalin avec des exceptions. Acre implique également qu'il couvre beaucoup de terrain. :-)

— Martin York