Dans les langages de programmation C et C ++, quelle est la différence entre l'utilisation de crochets angulaires et l'utilisation de guillemets dans une include
instruction, comme suit?
#include <filename>
#include "filename"
Dans les langages de programmation C et C ++, quelle est la différence entre l'utilisation de crochets angulaires et l'utilisation de guillemets dans une include
instruction, comme suit?
#include <filename>
#include "filename"
Réponses:
En pratique, la différence réside dans l'emplacement où le préprocesseur recherche le fichier inclus.
Pour #include <filename>
le préprocesseur recherche de manière dépendante de l'implémentation, normalement dans des répertoires de recherche pré-désignés par le compilateur / IDE. Cette méthode est normalement utilisée pour inclure des fichiers d'en-tête de bibliothèque standard.
Car #include "filename"
le préprocesseur recherche d'abord dans le même répertoire que le fichier contenant la directive, puis suit le chemin de recherche utilisé pour le #include <filename>
formulaire. Cette méthode est normalement utilisée pour inclure des fichiers d'en-tête définis par le programmeur.
Une description plus complète est disponible dans la documentation GCC sur les chemins de recherche .
#include <...>
utilisé le package installé sur le système et #include "..."
utilisé la version du référentiel à proximité. Je pourrais les avoir à l'envers. Dans les deux cas, le garde d'inclusion dans l'en-tête empaqueté est préfixé par un trait de soulignement. (Cela pourrait être une convention pour les packages ou peut-être un moyen d'empêcher délibérément de mélanger les deux, bien que les qualificatifs de version auraient plus de sens pour moi.)
La seule façon de le savoir est de lire la documentation de votre implémentation.
Dans la norme C , section 6.10.2, les paragraphes 2 à 4 stipulent:
Une directive de prétraitement du formulaire
#include <h-char-sequence> new-line
recherche une séquence de lieux définis par l' implémentation pour trouver un en- tête identifié de façon unique par la séquence spécifiée entre le
<
et>
délimiteurs, et provoque le remplacement de cette directive par le contenu de l' en- tête . La façon dont les emplacements sont spécifiés ou l'en-tête identifié est définie par l'implémentation.Une directive de prétraitement du formulaire
#include "q-char-sequence" new-line
provoque le remplacement de cette directive par l'ensemble du contenu du fichier source identifié par la séquence spécifiée entre les
"
délimiteurs. Le fichier source nommé est recherché d'une manière définie par l'implémentation. Si cette recherche n'est pas prise en charge, ou si la recherche échoue, la directive est retraitée comme si elle se lisait#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.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ée. Les jetons de prétraitement suivants
include
dans la directive sont traités comme dans le texte normal. (Chaque identificateur actuellement défini comme un nom de macro est remplacé par sa liste de remplacement de jetons de prétraitement.) La directive résultant après 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<
et une>
paire de jetons de prétraitement ou une paire de"
caractères est combinée en un seul 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 à l'exception du caractère de nouvelle ligne et
>
q-char: tout membre du jeu de caractères source à l'exception du caractère de nouvelle ligne et
"
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 à peu près libres d'utiliser la séquence de caractères comme elles le souhaitent. (Généralement, cependant, il suffit de le traiter comme un nom de fichier et de faire une recherche dans le chemin d'inclusion , comme l'indiquent les autres articles.)
Si le #include "file"
formulaire est utilisé, l'implémentation recherche d'abord un fichier du nom donné, s'il est pris en charge. Sinon (pris en charge) ou si la recherche échoue, l'implémentation se comporte comme si l'autre #include <file>
formulaire ( ) était utilisé.
En outre, un troisième formulaire existe et est utilisé lorsque la #include
directive ne correspond à aucun des formulaires ci-dessus. Sous cette forme, un prétraitement de base (tel qu'une expansion de macro) est effectué sur les "opérandes" de la #include
directive, et le résultat devrait correspondre à l'une des deux autres formes.
<
et >
comme clé pour indexer dans la bibliothèque.
Quelques bonnes réponses font ici référence au standard C mais ont oublié le standard POSIX, en particulier le comportement spécifique de la commande c99 (par exemple le compilateur C) .
Selon The Open Group Base Specifications Issue 7 ,
-I répertoire
Modifiez l'algorithme de recherche des en-têtes dont les noms ne sont pas des chemins d'accès absolus à rechercher dans le répertoire nommé par le chemin d'accès du répertoire avant de rechercher aux endroits habituels. Ainsi, les en-têtes dont les noms sont placés entre guillemets doubles ("") doivent être recherchés d'abord dans le répertoire du fichier avec la ligne #include , puis dans les répertoires nommés dans les options -I , et enfin aux endroits habituels. Pour les en-têtes dont les noms sont placés entre crochets ("<>"), l'en-tête doit être recherché uniquement 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é.Appel de la commande c99 .
Donc, dans un environnement compatible POSIX, avec un compilateur C compatible POSIX, #include "file.h"
va probablement chercher en ./file.h
premier, où .
est le répertoire où se trouve le fichier avec l' #include
instruction, tandis que #include <file.h>
, va probablement chercher en /usr/include/file.h
premier, où /usr/include
est votre système défini emplacements habituels pour les en-têtes (il ne semble pas défini par POSIX).
c99
- qui est le nom POSIX du compilateur C. (La norme POSIX 2008 pouvait difficilement faire référence à C11; la mise à jour 2013 de POSIX 2008 n'a pas changé la norme C à laquelle elle faisait référence.)
-L
.
La documentation de GCC indique ce qui suit sur 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 ajouter des répertoires à cette liste avec l'
-I
option (voir Invocation ).
#include "file"
Cette variante est utilisée pour les fichiers d'en-tête de votre propre programme. Il recherche un fichier nommé fichier d'abord dans le répertoire contenant le fichier actuel, puis dans les répertoires de devis et ensuite les mêmes répertoires que ceux utilisés
<file>
. Vous pouvez ajouter des répertoires à la liste des répertoires de devis avec l'-iquote
option. L'argument de‘#include’
, qu'il soit délimité par des guillemets ou des crochets, se comporte comme une constante de chaîne dans la mesure où les commentaires ne sont pas reconnus et les noms de macro 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
.Cependant, 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 en C n'est traitée. Ainsi,
#include "x\n\\y"
spécifie un nom de fichier contenant trois barres obliques inverses. (Certains systèmes interprètent «\» comme un séparateur de chemin d'accès. Tous ces éléments interprètent également de‘/’
la même manière. Il est plus portable à utiliser uniquement‘/’
.)C'est une erreur s'il y a quelque chose (autre que des commentaires) sur la ligne après le nom du fichier.
Cela fait:
"mypath/myfile" is short for ./mypath/myfile
avec .
soit le répertoire du fichier où le#include
est contenu, et / ou le répertoire de travail actuel du compilateur, et / oudefault_include_paths
et
<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile
Si ./
c'est le cas <default_include_paths>
, cela ne fait aucune différence.
Si se mypath/myfile
trouve dans un autre répertoire d'inclusion, le comportement n'est pas défini.
#include "mypath/myfile"
n'est pas équivalent à #include "./mypath/myfile"
. Comme le dit la réponse de piCookie, les guillemets doubles indiquent au compilateur de rechercher d'une manière définie par l'implémentation - ce qui inclut la recherche aux endroits spécifiés #include <...>
. (En fait, c'est probablement équivalent, mais seulement parce que, par exemple, /usr/include/mypath/myfile
on peut l'appeler /usr/include/./mypath/myfile
- au moins sur les systèmes de type Unix.)
defaultincludepaths
, au lieu de donner une autre signification au .
(comme mentionné ci-dessus). Cela a la conséquence attendue que les deux #include "..."
et la #include <...>
recherche dans dirpath
L' <file>
inclure indique le préprocesseur de rechercher dans les -I
répertoires et dans des répertoires prédéfinis d' abord , puis dans le répertoire du fichier .c. L' "file"
inclure indique le préprocesseur pour rechercher le répertoire du fichier source première , puis revenir à -I
et prédéfini. Toutes les destinations sont recherchées de toute façon, seul l'ordre de recherche est différent.
La norme 2011 traite principalement des fichiers inclus dans "16.2 Inclusion de fichiers 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 provoque le remplacement de cette directive par le contenu entier de l'en-tête. La façon dont les emplacements sont spécifiés ou l'en-tête identifié est définie par l'implémentation.
3 Une directive de prétraitement du formulaire
# include "q-char-sequence" new-line
entraîne le remplacement de cette directive par le contenu entier du fichier source identifié par la séquence spécifiée entre les "délimiteurs". Le fichier source nommé est recherché d'une manière définie par l'implémentation. Si cette recherche n'est pas prise en charge, ou si la recherche échoue , la directive est retraitée comme si elle se lisait
# 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.
Notez que le "xxx"
formulaire se dégrade en <xxx>
formulaire si le fichier est introuvable. Le reste est défini par l'implémentation.
-I
activité est spécifiée?
-I
.
#include <file.h>
indique au compilateur de rechercher l'en-tête dans son répertoire "includes", par exemple pour MinGW, le compilateur rechercherait file.h
dans C: \ MinGW \ include \ ou partout où votre compilateur est installé.
#include "file"
indique au compilateur de rechercher le répertoire courant (c'est-à-dire le répertoire dans lequel réside le fichier source) file
.
Vous pouvez utiliser l' -I
indicateur pour GCC pour lui indiquer que, lorsqu'il rencontre une inclusion avec des crochets angulaires, il doit également rechercher les en-têtes dans le répertoire après -I
. GCC traitera le répertoire après l'indicateur comme s'il s'agissait du includes
répertoire.
Par exemple, si vous avez un fichier appelé myheader.h
dans votre propre répertoire, vous pouvez dire #include <myheader.h>
si vous avez appelé GCC avec l'indicateur -I .
(indiquant qu'il doit rechercher les inclusions dans le répertoire actuel.)
Sans l' -I
indicateur, vous devrez utiliser #include "myheader.h"
pour inclure le fichier ou vous déplacer myheader.h
vers le include
répertoire de votre compilateur.
Selon la norme - oui, ils sont différents:
Une directive de prétraitement du formulaire
#include <h-char-sequence> new-line
recherche une séquence de lieux définis par l' implémentation pour trouver un en- tête identifié de façon unique par la séquence spécifiée entre le
<
et>
délimiteurs, et provoque le remplacement de cette directive par le contenu de l' en- tête. La façon dont les emplacements sont spécifiés ou l'en-tête identifié est définie par l'implémentation.Une directive de prétraitement du formulaire
#include "q-char-sequence" new-line
provoque le remplacement de cette directive par le contenu entier du fichier source identifié par la séquence spécifiée entre les
"
délimiteurs. Le fichier source nommé est recherché d'une manière définie par l'implémentation. Si cette recherche n'est pas prise en charge, ou si la recherche échoue, la directive est retraitée comme si elle se lisait#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.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ée. Les jetons de prétraitement suivants
include
dans la directive sont traités comme dans le texte normal. (Chaque identificateur actuellement défini comme un nom de macro est remplacé par sa liste de remplacement de jetons de prétraitement.) La directive résultant après 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<
et une>
paire de jetons de prétraitement ou une paire de"
caractères est combinée en un seul 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 à l'exception du caractère de nouvelle ligne et
>
q-char: tout membre du jeu de caractères source à l'exception du 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 (éventuellement autre) définie par l'implémentation. La norme spécifie également que certains fichiers include doivent être présents (par exemple, <stdio.h>
).
Formellement, vous devrez lire le manuel de votre compilateur, mais normalement (par tradition) le #include "..."
formulaire recherche le répertoire du fichier dans lequel le a #include
été trouvé en premier, puis les répertoires que le #include <...>
formulaire recherche (le chemin d'inclusion, par exemple les en-têtes du système) ).
Merci pour les bonnes réponses, esp. Adam Stelmaszczyk et piCookie, et aib.
Comme de nombreux programmeurs, j'ai utilisé la convention informelle d'utiliser le "myApp.hpp"
formulaire pour les fichiers spécifiques à l'application et le <libHeader.hpp>
formulaire pour les fichiers système de bibliothèque et de compilateur, c'est-à-dire les fichiers spécifiés dans /I
et la INCLUDE
variable d'environnement, pendant des années en pensant que c'était la norme.
Cependant, la norme C indique que l'ordre de recherche est spécifique à l'implémentation, ce qui peut compliquer la portabilité. Pour aggraver les choses, nous utilisons la confiture, qui détermine automatiquement où se trouvent les fichiers d'inclusion. 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 doubles barres obliques inverses (\\), mais maintenant ce n'est plus nécessaire. Je ne sais pas quand ça a changé. Utilisez simplement des barres obliques pour la compatibilité avec 'nix (Windows l'acceptera).
Si vous êtes vraiment inquiet à ce sujet, utilisez "./myHeader.h"
un fichier include dans le même répertoire que le code source (mon projet actuel très volumineux a des noms de fichiers include en double dispersés - vraiment un problème de gestion de la configuration).
Voici l' explication MSDN copiée ici pour votre commodité).
Formulaire cité
Le préprocesseur recherche les fichiers d'inclusion dans cet ordre:
- Dans le même répertoire que le fichier contenant l'instruction #include.
- Dans les répertoires des fichiers inclus actuellement ouverts, dans l'ordre inverse de
leur ouverture. La recherche commence dans le répertoire du fichier d'inclusion parent et se
poursuit vers le haut dans les répertoires de tout fichier d'inclusion de grand-parent.- Le long du chemin spécifié par chaque
/I
option du compilateur.- Le long des chemins qui sont spécifiés par la
INCLUDE
variable d'environnement.Forme de support d'angle
Le préprocesseur recherche les fichiers d'inclusion dans cet ordre:
- Le long du chemin spécifié par chaque
/I
option du compilateur.- Lorsque la compilation se produit sur la ligne de commande, le long des chemins spécifiés par la
INCLUDE
variable d'environnement.
Au moins pour la version GCC <= 3.0, la forme équerre 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épendance (en utilisant l'option GCC -M par exemple), vous devez utiliser le formulaire entre guillemets pour les fichiers qui doivent être inclus dans l'arbre de dépendance.
Un #include ""
compilateur recherche normalement le dossier du fichier qui contient cette inclusion, puis les autres dossiers. Pour #include <>
le compilateur ne recherche pas le dossier du fichier actuel.
<filename>
et "filename"
recherche des endroits définis par l'implémentation.
Lorsque vous utilisez #include <nomfichier>, le préprocesseur recherche le fichier dans le répertoire des fichiers d'en-tête C \ C ++ (stdio.h \ cstdio, chaîne, vecteur, etc.). Mais, lorsque vous utilisez #include "filename": d'abord, le préprocesseur recherche le fichier dans le répertoire courant, et s'il ne le fait pas ici - il le recherche dans le répertoire des fichiers d'en-tête C \ C ++.
#include
directive n'est pas du tout strictement liée aux fichiers.
Un #include avec des crochets cherchera une "liste d'emplacements dépendants 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 cherchera simplement un fichier (et, "d'une manière dépendante de l'implémentation", bleh). Ce qui signifie qu'en anglais normal, il essaiera d'appliquer le chemin / nom de fichier que vous lui lancez et ne ajoutera pas de chemin système ou ne le modifiera pas autrement.
De plus, si #include "" échoue, il est relu comme #include <> par la norme.
La documentation de gcc a une description (spécifique au compilateur) qui, bien qu'elle soit spécifique à gcc et non à la norme, est beaucoup plus facile à comprendre que le discours de style avocat des normes ISO.
zlib.h
dans mes chemins de recherche "utilisateur", et qu'une version différente existe dans le chemin de recherche du système, alors #include <zlib.h>
inclut la version du système et #include "zlib.h"
la mienne?
#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 <>
est pour les fichiers d'en-tête prédéfinisSi le fichier d'en-tête est prédéfini, vous écririez simplement le nom du fichier d'en-tête entre crochets angulaires, et cela ressemblerait à ceci (en supposant que nous avons 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éfinitSi vous (le programmeur) avez écrit votre propre fichier d'en-tête, vous écririez le nom du fichier d'en-tête entre guillemets. Supposons donc que vous ayez écrit un fichier d'en-tête appelé myfile.h
, alors voici un exemple de la façon dont vous utiliseriez la directive include pour inclure ce fichier:
#include "myfile.h"
De nombreuses réponses se concentrent ici sur les chemins que le compilateur recherchera afin de trouver le fichier. Bien que ce soit ce que font la plupart des compilateurs, un compilateur conforme est autorisé à être préprogrammé avec les effets des en-têtes standard, et à le 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 existe au moins un compilateur qui fonctionne de cette façon. L'utilisation #include <xxx>
uniquement avec des en-têtes standard est recommandée.
#include <abc.h>
est utilisé pour inclure des fichiers de bibliothèque standard. Ainsi, le compilateur vérifiera les emplacements où résident les en-têtes de bibliothèque standard.
#include "xyz.h"
indiquera au compilateur d'inclure les 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 les -I
dossiers définis.
En C ++, incluez un fichier de deux manières:
Le premier est #include qui indique au préprocesseur de rechercher le fichier à l'emplacement par défaut prédéfini. Cet emplacement est souvent une variable d'environnement INCLUDE qui indique le chemin d'accès pour inclure les 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.
Tout d'abord, recherche la présence du fichier d'en-tête dans le répertoire courant à partir duquel la directive est invoquée. S'il n'est pas trouvé, il recherche dans la liste préconfigurée des répertoires système standard.
Cela recherche la présence du fichier d'en-tête dans le répertoire courant d'où la directive est invoquée.
La liste exacte des répertoires de recherche dépend du système cible, de la configuration de GCC et de l'endroit où il est installé. Vous pouvez trouver la liste des répertoires de recherche de votre compilateur GCC en l'exécutant avec l'option -v.
Vous pouvez ajouter des répertoires supplémentaires au chemin de recherche en utilisant - I dir , ce qui entraîne la recherche de dir après le répertoire en cours (pour le formulaire de citation de la directive) et avant les répertoires système standard.
Fondamentalement, le formulaire "xxx" n'est rien d'autre qu'une recherche dans le répertoire courant; sinon trouvé retomber le formulaire
#include "header.h"
formulaire n'est pas exacte, @personal_cloud. Je considère que la réponse de piCookie et Yann Droneaud est la plus pertinente car ils identifient la provenance de leurs informations. Je ne trouve pas non plus la réponse la plus votée entièrement satisfaisante.
Le #include <filename>
est utilisé lorsqu'un fichier système est référencé. Il s'agit d'un fichier d'en-tête qui peut être trouvé aux 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 #include "filename"
syntaxe.
les recherches "<nom de fichier>" dans les emplacements de bibliothèque C standard
tandis que "nom de fichier" recherche également dans le répertoire courant.
Idéalement, vous utiliseriez <...> pour les bibliothèques C standard et "..." pour les bibliothèques que vous écrivez et qui sont présentes dans le répertoire courant.
La règle générale simple consiste à utiliser des crochets inclinés pour inclure les fichiers d'en-tête fournis avec le compilateur. Utilisez des guillemets doubles pour inclure tout autre fichier 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 de pré-processeur. Si vous êtes un programmeur débutant, cette page devrait vous aider à comprendre tout cela. Je l'ai appris d'ici et je l'ai suivi au travail.
#include <filename>
est utilisé lorsque vous souhaitez utiliser le fichier d'en-tête du système C / C ++ ou des bibliothèques du compilateur. 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. Lisez C - Préprocesseurs .
#include <filename>
#include "filename"
#include <filename>
et recherche ce fichier d'en-tête à l'endroit où les fichiers d'en-tête du système sont stockés.#include <filename>
.Pour voir l'ordre de recherche sur votre système à l'aide de gcc, en fonction de la configuration actuelle, vous pouvez exécuter la commande suivante. Vous pouvez trouver plus de détails sur cette commande ici
cpp -v /dev/null -o /dev/null
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Cible: x86_64-apple-darwin18.0.0
Modèle de thread: posix InstalledDir: Library / Developer / CommandLineTools / usr / bin
"/ Library / Developer / CommandLineTools / usr / bin / clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage -Werror = deprecated-objc-isa-usage -E -disable-free - disable-llvm-verifier -discard-value-names -main-file-name null -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose - munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning = lldb -target-linker-version 409.12 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 - isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -I / usr / local / include -fdebug-compilation-dir / Users / hogstrom -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime = macosx-10.14.0 -fmax-type-align = 16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -xc / dev / null
clang -cc1 version 10.0.0 (clang-1000.10.44.2) cible par défaut x86_64-apple-darwin18.0.0 ignorant le répertoire inexistant "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/local/include" ignorant inexistant répertoire "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." la recherche commence ici:
#include <...> la recherche commence ici:
/ usr / local / include
/ Library / Developer / CommandLineTools / usr / lib / clang / 10.0.0 / include
/ Library / Developer / CommandLineTools / usr / include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
/ Library / Developer / CommandLineTools / SDKs / MacOSX10.14.sdk / System / Library / Frameworks (répertoire framework)
Fin de la liste de recherche.
Il existe deux façons d'écrire une instruction #include, à savoir:
#include"filename"
#include<filename>
La signification de chaque forme est
#include"mylib.h"
Cette commande rechercherait le fichier mylib.h
dans le répertoire courant ainsi que la liste de répertoires spécifiée comme mentionné dans le chemin de recherche d'inclusion qui aurait pu être configuré.
#include<mylib.h>
Cette commande rechercherait le fichier mylib.h
dans la liste de répertoires spécifiée uniquement.
Le chemin de recherche inclus n'est rien d'autre qu'une liste de répertoires qui seraient recherchés pour le fichier inclus. Différents compilateurs C vous permettent de définir le chemin de recherche de différentes manières.