<iostream> vs vs <iostream.h> « iostream.h »

Question

En incluant un fichier d'en-tête en C++, quelle est la différence entre ...

1), y compris les .h par rapport aux non compris le .h lors de l'envelopper dans < > signes?

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

2) enveloppant le nom d'en-tête entre guillemets par rapport à l'envelopper dans <> signes?

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

Merci d'avance!

Answer 1

En bref:

iostream.h est dépréciée - il est la version originale Stroustrup, et iostream est la version du comité des normes. Généralement, les compilateurs pointent les deux vers la même chose, mais certains compilateurs plus anciens n'auront pas l'ancien. Dans certains cas, ils existeront et seront différents (pour supporter le code existant) et vous devrez alors être spécifique.

"" par rapport à <> signifie simplement vérifier les répertoires locaux pour l'en-tête avant d'aller à la bibliothèque (dans la plupart des compilateurs).

-Adam

Answer 2

Voici un lien décent article.

Pour résumer, la raison donnée:

La version de la bibliothèque iostream que le Comité des normes produit était un peu différent de la mise en œuvre cfront. {} snip

Pour faciliter la transition, le Comité des normes C++ a déclaré que le code y compris les en-têtes C++ standard utiliseraient notamment des directives qui manque une extension. Cela a permis aux fournisseurs de compilateurs d'expédier les anciens en-têtes de bibliothèque C++ avec l'extension .h et les nouveaux en-têtes de style sans.

Un avantage de ne pas utiliser la version .h:

Il y a plusieurs raisons pour lesquelles le nouveau code doit être écrit en utilisant la version de fichiers sans extension des en-tête au lieu des formes .h. Le est d'abord l'imprévisibilité d'un tel code lorsqu'il est compilé sur les compilateurs modernes . Comme mentionné précédemment, le résultat de l'utilisation des en-têtes .h est spécifique à l'implémentation. Et au fil du temps, la probabilité qu'un compilateur donné ait l'ancienne bibliothèque de styles diminue.

Answer 3

Généralement, <> est utilisé pour les fichiers de bibliothèque système ou standard alors que "" est utilisé pour les fichiers de projet. Je ne serais pas surpris si votre compilateur recherche localement et quand il ne peut pas le trouver, il est par défaut à la version de la bibliothèque standard. En ce qui concerne le .h, je ne pense pas que cela a vraiment d'importance si vous utilisez C. En C++, je me souviens vaguement qu'il y avait une version plus récente et une version plus ancienne et que sans le h il était censé être la nouvelle version, mais je ne suis même pas sûr que l'ancienne version existe toujours.

Answer 4

La méthode standard (et le seul garanti au travail) est <iostream>. Sur gcc, <iostream.h> (qui peut avoir besoin d'être inclus en tant que <backward/iostream.h>) tire les déclarations pertinentes vers l'espace de noms global (vous n'avez donc pas besoin du préfixe std :: namespace). "Iostream.h" essayera d'abord du répertoire avec votre code source, puisque "" est destiné aux en-têtes de votre projet. < > devrait toujours être utilisé pour les en-têtes du système, et "" pour vos propres en-têtes.

Answer 5

La réponse simple à la première réponse est que iostream.h n'existe pas, au moins dans l'implémentation de GCC. Si vous êtes sur * nix, le type

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

et

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

Comme l'article de Zee dit, iostream.h est pour la compatibilité descendante.

Answer 6

Ce sont vraiment deux questions différentes.

• La différence entre les .h et têtes avec le même sans extension nom est historique. Ceux avec l'extension .h sont de la norme C++ originale qui n'a pas ont des fonctionnalités modernes telles que espaces de noms et des modèles. Il était plus simple pour la nouvelle norme pour mettre cette même fonctionnalité dans les nouveaux fichiers d'en-tête pour pouvoir utiliser ces nouvelles fonctionnalités et garder les anciens (.h) fichiers pour la compatibilité descendante de code existant.

• La différence entre les #include < ...> et #include "..." est le format l'ordre dans lequel le compilateur recherche les fichiers. Ceci est généralement dépendant de l'implémentation, mais l'idée est que le <> format est dans le système include premier, tandis que « » regarde dans le même répertoire que le fichier source qui #include il premier.

Answer 7

En tant que personne au comité des normes (X3J16) qui a proposé de quitter au large de la .h, mon intention initiale était de régler le débat sur .h, .H, .hpp, .hxx ou .h ++ fichier extensions; ou un désir par certains qu'il n'y ait aucune implication dans la norme que c'était le nom d'un fichier sur le disque afin de permettre à un EDI d'extraire des informations d'en-tête pré-compilées d'un endroit interne comme un fichier de ressources ou même les tripes du compilateur.Alors qu'Unix considérait le nom de fichier comme une chaîne unique et ne reconnaissait pas vraiment le concept d'extension, les systèmes d'exploitation DEC avaient pour habitude de séparer le nom de l'extension et de fournir "l'extension par défaut" si elle était omise dans des contextes particuliers. C'est là que j'ai eu l'idée de laisser l'implémentation utiliser l'extension que l'implémentation voulait utiliser, et cela a permis à l'implémentation de ne même pas avoir un fichier sur le disque. (J'étais le représentant de DEC au comité à l'époque.)

La différenciation entre les en-têtes standard et pré-standard était un avantage supplémentaire.