c++ - priority - include c




Quelle est la différence entre#include<filename> et#include "filename"? (20)

Dans les langages de programmation C et C ++, quelle est la différence entre l'utilisation de chevrons et l'utilisation de guillemets dans une instruction include , comme suit?

  1. #include <filename>
  2. #include "filename"

the " < filename > " searches in standard C library locations

whereas "filename" searches in the current directory as well.

Ideally, you would use <...> for standard C libraries and "..." for libraries that you write and are present in the current directory.


#include <filename>

est utilisé lorsque vous souhaitez utiliser le fichier d'en-tête du système C / C ++ ou des bibliothèques de compilation. Ces bibliothèques peuvent être stdio.h, string.h, math.h, etc.

#include "path-to-file/filename"

est utilisé lorsque vous souhaitez utiliser votre propre fichier d'en-tête personnalisé qui se trouve dans votre dossier de projet ou ailleurs.

Pour plus d'informations sur les préprocesseurs et l'en-tête. Lire C - Préprocesseurs .


Cela fait:

"mypath/myfile" is short for ./mypath/myfile

avec . étant soit le répertoire du fichier où se trouve le #include , et / ou le répertoire de travail courant du compilateur, et / ou le default_include_paths

et

<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile

Si ./ est dans <default_include_paths> , cela ne fait aucune différence.

Si mypath/myfile trouve dans un autre répertoire include, le comportement n'est pas défini.


En C ++, incluez un fichier de deux manières:

Le premier est #include qui indique au préprocesseur de rechercher le fichier dans l'emplacement par défaut prédéfini. Cet emplacement est souvent une variable d'environnement INCLUDE qui indique le chemin d'inclusion des fichiers.

Et le deuxième type est #include "filename" qui indique au préprocesseur de rechercher d'abord le fichier dans le répertoire courant, puis de le rechercher dans les emplacements prédéfinis que l'utilisateur a configurés.


Je crois que les en-têtes inclus dans les guillemets seront recherchés dans les mêmes chemins du système que les angles entre crochets s'ils ne sont pas trouvés dans le répertoire courant.


L'include <file> indique au préprocesseur de rechercher d'abord dans les répertoires -I et dans les répertoires prédéfinis, puis dans le répertoire du fichier .c. Le "file" include "file" indique au préprocesseur de rechercher d'abord le répertoire du fichier source, puis de revenir à -I et de le prédéfinir. Toutes les destinations sont recherchées de toute façon, seul l'ordre de recherche est différent.

La norme de 2011 traite principalement des fichiers d'inclusion dans «16.2 Inclusion du fichier source».

2 Une directive de pré-traitement du formulaire

# include <h-char-sequence> new-line

recherche une séquence d'emplacements définis par l'implémentation pour un en-tête identifié uniquement par la séquence spécifiée entre les délimiteurs <et>, et entraîne le remplacement de cette directive par l'intégralité du contenu de l'en-tête. La façon dont les lieux sont spécifiés ou l'en-tête identifié est défini par l'implémentation.

3 Une directive de pré-traitement du formulaire

# include "q-char-sequence" new-line

provoque le remplacement de cette directive par tout le contenu du fichier source identifié par la séquence spécifiée entre les délimiteurs Le fichier source nommé est recherché selon une implémentation définie Si cette recherche n'est pas prise en charge ou si la recherche échoue , la directive est retraitée comme si elle était lue

# include <h-char-sequence> new-line

avec la séquence contenue identique (y compris> les caractères, le cas échéant) de la directive d'origine.

Notez que le formulaire "xxx" se dégrade en formulaire <xxx> si le fichier n'est pas trouvé. Le reste est défini par l'implémentation.


La règle générale simple consiste à utiliser des parenthèses inclinées pour inclure les fichiers d'en-tête fournis avec le compilateur. Utilisez des guillemets doubles pour inclure tous les autres fichiers d'en-tête. La plupart des compilateurs le font de cette façon.

1.9 - Les fichiers d'en-tête expliquent plus en détail les directives du pré-processeur. Si vous êtes un programmeur novice, cette page devrait vous aider à comprendre tout cela. Je l'ai appris d'ici, et je l'ai suivi au travail.


La séquence de caractères entre <et> fait uniquement référence à un en-tête, qui n'est pas nécessairement un fichier. Les implémentations sont pratiquement libres d'utiliser la séquence de caractères comme ils le souhaitent. (La plupart du temps, il suffit de le traiter comme un nom de fichier et d'effectuer une recherche dans le chemin d'inclusion , comme dans les autres publications.)

Si le formulaire #include "file" est utilisé, l'implémentation recherche d'abord un fichier du nom donné, s'il est pris en charge. Sinon (supporté), ou si la recherche échoue, l'implémentation se comporte comme si l'autre forme ( #include <file> ) était utilisée.

En outre, une troisième forme existe et est utilisée lorsque la directive #include ne correspond à aucun des formulaires ci-dessus. Dans cette forme, un pré-traitement de base (tel que la macro-expansion) est effectué sur les "opérandes" de la directive #include , et le résultat devrait correspondre à l'un des deux autres formulaires.


Le #include <filename> est utilisé lorsqu'un fichier système est référencé. C'est un fichier d'en-tête qui peut être trouvé dans les emplacements par défaut du système comme /usr/include ou /usr/local/include . Pour vos propres fichiers qui doivent être inclus dans un autre programme, vous devez utiliser la syntaxe #include "filename" .


Merci pour les bonnes réponses, esp. Adam Stelmaszczyk et piCookie, et aib.

Comme beaucoup de programmeurs, j'ai utilisé la convention informelle d'utiliser le "myApp.hpp" pour les fichiers spécifiques aux applications, et le <libHeader.hpp> pour les fichiers système de la bibliothèque et du compilateur, ie les fichiers spécifiés dans /I et la variable d'environnement INCLUDE , pendant des années en pensant que c'était la norme.

Cependant, la norme C stipule que l'ordre de recherche est spécifique à l'implémentation, ce qui peut compliquer la portabilité. Pour aggraver les choses, nous utilisons jam, qui détermine automatiquement où les fichiers include sont. Vous pouvez utiliser des chemins relatifs ou absolus pour vos fichiers d'inclusion. c'est à dire

#include "../../MyProgDir/SourceDir1/someFile.hpp"

Les anciennes versions de MSVS nécessitaient des antislashs doubles (\\), mais ce n'est pas obligatoire. Je ne sais pas quand ça a changé. Utilisez juste des barres obliques pour la compatibilité avec 'nix (Windows acceptera cela).

Si vous êtes vraiment inquiet à ce sujet, utilisez "./myHeader.h" pour un fichier d'inclusion dans le même répertoire que le code source (mon projet actuel, très volumineux a des noms de fichiers d'inclusion en double dispersés - vraiment un problème de gestion de configuration ).

Voici l' explication MSDN copiée ici pour votre commodité).

Formulaire cité

Le préprocesseur recherche les fichiers d'inclusion dans cet ordre:

  1. Dans le même répertoire que le fichier contenant l'instruction #include.
  2. Dans les répertoires des fichiers d'inclusion actuellement ouverts, dans l'ordre inverse dans lequel
    ils ont été ouverts. La recherche commence dans le répertoire du fichier include parent et
    continue vers le haut à travers les répertoires de tous les fichiers d'inclusion de grands-parents.
  3. Le long du chemin spécifié par chaque option /I compilateur.
  4. Le long des chemins spécifiés par la variable d'environnement INCLUDE .

Forme de cornière

Le préprocesseur recherche les fichiers d'inclusion dans cet ordre:

  1. Le long du chemin spécifié par chaque option /I compilateur.
  2. Lorsque la compilation se produit sur la ligne de commande, le long des chemins spécifiés par la variable d'environnement INCLUDE .

Pour #include "nomfichier", le préprocesseur recherche dans le même répertoire que le fichier contenant la directive. Cette méthode est normalement utilisée pour inclure des fichiers d'en-tête définis par le programmeur.

Pour #include, le préprocesseur recherche de manière dépendante de l'implémentation, normalement dans les répertoires de recherche pré-désignés par le compilateur / IDE. This method is normally used to include standard library header files.


Pour #include "" un compilateur recherche normalement le dossier du fichier qui contient cet include, puis les autres dossiers. Pour #include <> le compilateur ne recherche pas le dossier du fichier en cours.


Un #include avec des chevrons cherchera une "liste de lieux dépendant de l'implémentation" (ce qui est une manière très compliquée de dire "en-têtes système") pour le fichier à inclure.

Un #include avec des guillemets recherchera simplement un fichier (et, "d'une manière dépendant de l'implémentation", bleh). Ce qui signifie, en anglais normal, qu'il va essayer d'appliquer le chemin / nom de fichier que vous lancez dessus et ne pas préfixer un chemin système ou le falsifier autrement.

En outre, si #include "" échoue, il est relu comme #include <> par la norme.

La g++ a une description (spécifique au compilateur) qui, bien qu'étant spécifique à gcc et non standard, est beaucoup plus facile à comprendre que le discours de style avocat des normes ISO.


La documentation de GCC dit ce qui suit à propos de la différence entre les deux:

Les fichiers d'en-tête utilisateur et système sont inclus à l'aide de la directive de prétraitement '#include' . Il a deux variantes:

#include <file>

Cette variante est utilisée pour les fichiers d'en-tête système. Il recherche un fichier nommé fichier dans une liste standard de répertoires système. Vous pouvez préfixer les répertoires à cette liste avec l'option -I (voir Invocation ).

#include "file"

Cette variante est utilisée pour les fichiers d'en-tête de votre propre programme. Il recherche d'abord un fichier nommé fichier dans le répertoire contenant le fichier en cours, puis dans les répertoires quote, puis les mêmes répertoires que ceux utilisés pour <file> . Vous pouvez ajouter les répertoires à la liste des répertoires avec l'option -iquote . L'argument de '#include' , qu'il soit délimité par des guillemets ou des chevrons, se comporte comme une chaîne de caractères dans la mesure où les commentaires ne sont pas reconnus et les noms de macros ne sont pas développés. Ainsi, #include <x/*y> spécifie l'inclusion d'un fichier d'en-tête système nommé x/*y .

Toutefois, si des barres obliques inverses se produisent dans le fichier, elles sont considérées comme des caractères de texte ordinaires et non comme des caractères d'échappement. Aucune des séquences d'échappement de caractères appropriées aux constantes de chaîne dans C n'est traitée. Ainsi, #include "x\n\\y" spécifie un nom de fichier contenant trois antislashs. (Certains systèmes interprètent '\' comme un séparateur de chemin, et tous interprètent '/' la même manière, il est plus portable de n'utiliser que '/' .)

C'est une erreur s'il y a quelque chose (autre que des commentaires) sur la ligne après le nom du fichier.


#include <filename>

will find the corresponding file from the C++ library. it means if you have a file called hello.h in the C++ library folder, #include <hello.h> will load it.

Mais,

#include "filename"

will find the file in the same directory where your source file is.

In addition,

#include "path_to_file/filename"

will find the file in the directory which you typed in path_to_file .


The order of search header files is different. <XXX.h> prefer to search the standard headers first while "XXX.h" searches the workspace's header files first.


When you use #include <filename>, the pre-processor looking for the file in directtory of C\C++ header files (stdio.h\cstdio, string, vector, etc.). But, when you use #include "filename": first, the pre-processor looking for the file in the current directory, and if it doesn't here - he looking for it in the directory of C\C++ header files.


  #include <filename>   (1)     
  #include "filename"   (2)

#include inclut le fichier source, identifié par le nom de fichier, dans le fichier source actuel sur la ligne immédiatement après la directive.

La première version de la directive recherche uniquement les répertoires d'inclusion standard. La bibliothèque C ++ standard, ainsi que la bibliothèque C standard, est implicitement incluse dans les répertoires include standard. Les répertoires include standard peuvent être contrôlés par l'utilisateur via les options du compilateur.

La deuxième version recherche d'abord le répertoire où se trouve le fichier actuel et, uniquement si le fichier n'est pas trouvé, effectue une recherche dans les répertoires d'inclusion standard.

Dans le cas où le fichier n'est pas trouvé, le programme est mal formé.


#include <abc.h>

est utilisé pour inclure les fichiers de bibliothèque standard. Le compilateur vérifie donc les emplacements où résident les en-têtes de bibliothèque standard.

#include "xyz.h"

dira au compilateur d'inclure des fichiers d'en-tête définis par l'utilisateur. Ainsi, le compilateur vérifiera ces fichiers d'en-tête dans le dossier actuel ou dans les dossiers définis -I .


  • #include <> est pour les fichiers d'en-tête prédéfinis

Si le fichier d'en-tête est prédéfini, vous devez simplement écrire le nom du fichier d'en-tête dans des parenthèses angulaires, et cela ressemblerait à ceci (en supposant que nous ayons un nom de fichier d'en-tête prédéfini iostream):

#include <iostream>
  • #include " " est pour les fichiers d'en-tête que le programmeur définit

Si vous (le programmeur) écriviez votre propre fichier d'en-tête, vous écririez le nom du fichier d'en-tête entre guillemets. Donc, supposons que vous ayez écrit un fichier d'en-tête appelé myfile.h , alors myfile.h un exemple de la façon dont vous utiliseriez la directive include pour inclure ce fichier:

#include "myfile.h"




c-preprocessor