c++ priority Quelle est la différence entre#include<filename> et#include "filename"?




include c (24)

#include <file> tells the compiler to search for the header in its includes directory, eg for MinGW the compiler would search for file in C:\MinGW\include\ or wherever your compiler is installed.

#include "file" tells the compiler to search the current directory (ie the directory in which the source file resides) for file .

You can use the -I flag for GCC to tell it that, when it encounters an include with angled brackets, it should also search for headers in the directory after -I . For instance, if you have a file called myheader.h in your own directory, you could say #include <myheader.h> if you called GCC with -I . (indicating that it should search for includes in the current directory.)

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"

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.


Au moins pour la version GCC <= 3.0, la forme de crochet d'angle ne génère pas de dépendance entre le fichier inclus et le fichier inclus.

Donc, si vous voulez générer des règles de dépendances (en utilisant l'option GCC -M par exemple), vous devez utiliser le formulaire quoté pour les fichiers qui doivent être inclus dans l'arbre de dépendance.

(Voir http://gcc.gnu.org/onlinedocs/cpp/Invocation.html )


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.


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.


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


To include a predefined library header file , #include<filename> is used whereas to include user defined header file, #include "filename" is relevant.


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.


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.


Quelques bonnes réponses ici font référence au standard C mais ont oublié le standard POSIX, en particulier le comportement spécifique de la commande c99 (compilateur C par exemple) .

Selon The Open Group Base Specifications Numéro 7 ,

-I répertoire

Changez l'algorithme de recherche des en-têtes dont les noms ne sont pas des noms de chemins absolus à chercher dans le répertoire nommé par le chemin d'accès au répertoire avant de chercher aux endroits habituels. Ainsi, les en-têtes dont les noms sont entre guillemets ("") seront recherchés d'abord dans le répertoire du fichier avec la ligne #include , puis dans les répertoires nommés en -I options, et en dernier lieu aux endroits habituels. Pour les en-têtes dont les noms sont entre crochets ("<>"), l'en-tête ne doit être recherché que dans les répertoires nommés dans les options -I , puis aux endroits habituels. Les répertoires nommés dans les options -I doivent être recherchés dans l'ordre spécifié. Les implémentations doivent prendre en charge au moins dix instances de cette option dans une seule invocation de commande c99 .

Ainsi, dans un environnement compatible POSIX, avec un compilateur C compatible POSIX, #include "file.h" va probablement rechercher ./file.h abord, où . est le répertoire où se trouve le fichier avec l'instruction #include , alors que #include <file.h> , va probablement chercher /usr/include/file.h abord, où /usr/include est votre emplacement habituel défini par le système pour en-têtes (il ne semble pas défini par POSIX).


Par la norme - oui, ils sont différents:

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

  • 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 > caractères, le cas échéant) de la directive d'origine.

  • Une directive de pré-traitement du formulaire

    #include pp-tokens new-line
    

    (qui ne correspond pas à l'une des deux formes précédentes) est autorisé. Les jetons de prétraitement après include dans la directive sont traités comme dans le texte normal. (Chaque identifiant actuellement défini en tant que nom de macro est remplacé par sa liste de remplacement de jetons de prétraitement.) La directive résultant de tous les remplacements doit correspondre à l'un des deux formulaires précédents. La méthode par laquelle une séquence de jetons de prétraitement entre une paire de jetons de prétraitement < et une paire de caractères est combinée dans un jeton de prétraitement de nom d'en-tête est définie par l'implémentation.

Définitions

  • h-char: tout membre du jeu de caractères source sauf le caractère de nouvelle ligne et >

  • q-char: tout membre du jeu de caractères source sauf le caractère de nouvelle ligne et "

Notez que la norme ne dit aucune relation entre les manières définies par l'implémentation. Le premier formulaire recherche d'une manière définie par l'implémentation et l'autre d'une manière définie par l'implémentation (éventuellement autre). La norme spécifie également que certains fichiers include doivent être présents (par exemple, <stdio.h> ).

Formellement vous auriez à lire le manuel pour votre compilateur, cependant normalement (par tradition) le formulaire #include "..." recherche dans le répertoire du fichier dans lequel le #include été trouvé en premier, et ensuite les répertoires que le #include <...> recherches de formulaire #include <...> (le chemin d'inclusion, par exemple les en-têtes de système).


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


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


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.


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.


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.


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.


  • #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"

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


La plupart des réponses se concentrent sur les chemins que le compilateur cherchera pour trouver le fichier. Tandis que c'est ce que font la plupart des compilateurs, un compilateur conforme peut être préprogrammé avec les effets des en-têtes standard, et traiter, par exemple, #include <list> comme un commutateur, et il n'a pas besoin d'exister en tant que fichier.

Ce n'est pas purement hypothétique. Il y a au moins un compilateur qui fonctionne de cette façon. L'utilisation de #include <xxx> uniquement avec des en-têtes standard est recommandée.


#include "filename" // User defined header
#include <filename> // Standard library header.

Exemple:

Le nom de fichier ici est Seller.h :

#ifndef SELLER_H     // Header guard
#define SELLER_H     // Header guard

#include <string>
#include <iostream>
#include <iomanip>

class Seller
{
    private:
        char name[31];
        double sales_total;

    public:
        Seller();
        Seller(char[], double);
        char*getName();

#endif

Dans l'implémentation de classe (par exemple, Seller.cpp , et dans d'autres fichiers qui utiliseront le fichier Seller.h ), l'en-tête défini par l'utilisateur doit maintenant être inclus, comme suit:

#include "Seller.h"

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


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.


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 .




c-preprocessor