Question

Lors de l'inclusion d'un fichier d'en-tête dans C ++, quelle est la différence entre ...

1) incluant le .h ou non .h lorsqu’il est enveloppé dans < > des signes?

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

2) Envelopper le nom de l'en-tête entre guillemets et l'envelopper dans < > des signes?

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

Merci d'avance!

Était-ce utile?

La solution

En bref:

iostream.h est obsolète. Il s'agit de la version d'origine de Stroustrup et iostream est la version du comité des normes. Généralement, les compilateurs indiquent la même chose, mais certains compilateurs plus anciens n'auront pas l'ancien. Dans certains cas étranges, ils existeront et seront différents (pour prendre en charge le code hérité) 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 dans la bibliothèque (dans la plupart des compilateurs).

-Adam

Autres conseils

Voici un lien décent article.

Pour résumer, la raison donnée:

  

La version de la bibliothèque iostream que le comité de normalisation   produit était assez différent de la mise en œuvre de 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 les directives include   manque une extension. Cela a permis aux vendeurs de compilateur d'expédier l'ancien style   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 le   version sans extension des fichiers d'en-tête au lieu des formulaires .h. le   d’abord, l’imprévisibilité de ce code lorsqu’il est compilé sur des bases modernes   compilateurs. Comme mentionné précédemment, le résultat de l'utilisation des en-têtes .h   est spécifique à la mise en œuvre. Et au fil du temps, la chance qu’un   le compilateur donné aura l’ancienne bibliothèque de styles disponible diminuée.

En tant que membre du comité de normalisation (X3J16) qui a proposé d’abandonner le fichier .h, mon intention initiale était de régler le débat sur les extensions de fichier .h, .H, .hpp, .hxx ou .h ++; ou le souhait de certains qu'il n'y ait aucune implication dans la norme qu'il s'agisse du nom d'un fichier sur disque afin de permettre à un IDE d'extraire des informations d'en-tête pré-compilées de quelque part interne, comme un fichier de ressources, ou même du courage de l'utilisateur. compilateur.

Alors qu'Unix considérait le nom de fichier comme une chaîne unique et ne reconnaissait pas le concept d'extension, les systèmes d'exploitation DEC avaient l'habitude de séparer le nom de l'extension et de fournir "l'extension par défaut". s'il a été omis dans des contextes particuliers. C’est là que j’ai eu l’idée de laisser l’implémentation utiliser l’extension souhaitée, ce qui a permis à l’implémentation de ne même pas enregistrer ce fichier sur un disque. (J'étais le représentant de DEC au comité à l'époque.)

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

La manière standard (et la seule garantie de fonctionner) est . Sur gcc, < iostream.h > (qui doit éventuellement être inclus sous la forme < backward / iostream.h >) extrait les déclarations pertinentes dans l’espace de noms global (vous n’avez donc pas besoin du préfixe std :: namespace).

" iostream.h " essaierait d’abord du répertoire avec votre code source, car " " est destiné aux en-têtes de votre projet. < > doit toujours être utilisé pour les en-têtes de système et " " pour vos propres en-têtes.

Typiquement < > 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 effectue des recherches localement et s’il ne parvient pas à le trouver, il utilise par défaut la version standard de la bibliothèque.

En ce qui concerne le .h, je ne pense pas que ce soit vraiment important 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 la lettre h, elle était supposée être la nouvelle version, mais je ne suis même pas sûr que l'ancienne version existe encore.

Ce sont vraiment deux questions différentes.

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

  • La différence entre le #include < ... > et #include " ... " le format est l'ordre dans lequel le compilateur cherche des fichiers. C'est généralement dépend de la mise en œuvre, mais le L’idée est que les < > format regarde dans les répertoires d'inclusion système d'abord, pendant que " " regarde dans le même répertoire en tant que fichier source qui l'a inclus premier.

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

% localisez iostream.h
/ usr / include / c ++ / 3.4.3 / arriéré / iostream.h

et

% localisez iostream
/usr/include/c++/3.4.3/iostream
/ usr / include / c ++ / 3.4.3 / arriéré / iostream.h

Comme le dit l'article de Zee, iostream.h est destiné à la compatibilité ascendante.

En ce qui concerne les noms des fichiers d’en-tête C ++ standard, au début des deux premières années de X3J16, nous nous sommes heurtés à un argument sur la question de savoir quelle devrait être l’extension des fichiers d’en-tête C ++ standard. Utilisé à l'époque par différents fournisseurs (et influencé par les contraintes imposées par certains systèmes d'exploitation sur les noms de fichiers), je crois qu'il y avait .h, .H, .h ++, .hpp, .HXX et peut-être d'autres. Lors d'une réunion de groupe de bibliothèques, j'ai suggéré de laisser l'extension désactivée et de laisser à l'implémentation le soin de fournir une extension de fichier par défaut de son choix s'il n'y en avait aucune dans la ligne d'inclusion, ou d'utiliser le nom comme clé dans une base de données de fichiers d'en-tête pré-compilés si vous le souhaitez. [Bien que les systèmes de type Unix traitent le nom de fichier et "extension" comme une seule chaîne, je représentais DEC au comité et de nombreux systèmes d'exploitation DEC stockaient l'extension dans le répertoire sous la forme d'un champ distinct du nom. Les systèmes d’exploitation de DEC ont donc traditionnellement appliqué une extension par défaut en fonction du programme qui accédait au fichier et dans quel but. Dire à un assembleur 'X, Y = Z' peut entraîner la lecture du fichier d'entrée Z.MAC (macro) et l'écriture des fichiers de sortie X.OBJ et Y.LST.] Quoi qu'il en soit, cela évitait un long débat sans issue, ainsi le groupe Andy Koenig a présenté les conclusions du groupe à ce sujet (parmi d’autres) à l’ensemble du comité qui l’a accepté. Je trouve quelque peu amusant que les implémentations n’aient pas compris le fait qu’elles pourraient appliquer une extension par défaut de leur choix (ce qui, à mon avis, serait utile aux éditeurs et autres outils) et qu’elles ont simplement laissé l’extension du nom de fichier.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top