Nei linguaggi di programmazione C e C ++, qual è la differenza tra l'uso delle parentesi angolari e l'uso delle virgolette in include
un'istruzione, come segue?
#include <filename>
#include "filename"
Nei linguaggi di programmazione C e C ++, qual è la differenza tra l'uso delle parentesi angolari e l'uso delle virgolette in include
un'istruzione, come segue?
#include <filename>
#include "filename"
Risposte:
In pratica, la differenza sta nella posizione in cui il preprocessore cerca il file incluso.
Per #include <filename>
il preprocessore ricerche in modo dipendente dall'implementazione, normalmente nelle directory di ricerca predefinite dal compilatore / IDE. Questo metodo viene normalmente utilizzato per includere file di intestazione della libreria standard.
Il #include "filename"
preprocessore cerca prima nella stessa directory del file contenente la direttiva, quindi segue il percorso di ricerca utilizzato per il #include <filename>
modulo. Questo metodo viene normalmente utilizzato per includere file di intestazione definiti dal programmatore.
Una descrizione più completa è disponibile nella documentazione GCC sui percorsi di ricerca .
#include <...>
usato il pacchetto installato sul sistema e ho #include "..."
usato la versione del repository vicina. Potrei avere quelli al contrario. In entrambi i casi, la protezione include nell'intestazione del pacchetto è preceduta da un carattere di sottolineatura. (Potrebbe essere una convenzione per i pacchetti o forse un modo per impedire deliberatamente di mescolare i due, anche se i qualificatori di versione avrebbero più senso per me.)
L'unico modo per sapere è leggere la documentazione dell'implementazione.
Nella norma C , sezione 6.10.2, i paragrafi da 2 a 4 stabiliscono:
Una direttiva di preelaborazione del modulo
#include <h-char-sequence> new-line
ricerche una sequenza di luoghi di attuazione definite per un'intestazione identificato univocamente dalla sequenza specificata tra la
<
e>
delimitatori, e provoca la sostituzione di tale direttiva da parte intero contenuto del intestazione . Il modo in cui i luoghi vengono specificati o l'header identificato è definito dall'implementazione.Una direttiva di preelaborazione del modulo
#include "q-char-sequence" new-line
provoca la sostituzione di tale direttiva con l'intero contenuto del file sorgente identificato dalla sequenza specificata tra i
"
delimitatori. Il nome file di origine viene cercato in un modo definito dall'implementazione. Se questa ricerca non è supportata o se la ricerca fallisce, la direttiva viene rielaborata come se fosse letta#include <h-char-sequence> new-line
con la stessa sequenza contenuta (inclusi eventuali
>
caratteri) dalla direttiva originale.Una direttiva di preelaborazione del modulo
#include pp-tokens new-line
(che non corrisponde a uno dei due moduli precedenti) è consentito. I token di preelaborazione successivi
include
nella direttiva vengono elaborati proprio come nel testo normale. (Ogni identificatore attualmente definito come nome di macro è sostituito dal suo elenco di token di preelaborazione di sostituzione.) La direttiva risultante dopo tutte le sostituzioni deve corrispondere a una delle due forme precedenti. Il metodo con cui una sequenza di token di preelaborazione tra una<
e una>
coppia di token di preelaborazione o una coppia di"
caratteri viene combinata in un singolo token di preelaborazione del nome di intestazione è definito dall'implementazione.definizioni:
h-char: qualsiasi membro del set di caratteri di origine tranne il carattere di nuova riga e
>
q-char: qualsiasi membro del set di caratteri di origine tranne il carattere di nuova riga e
"
La sequenza di caratteri tra <e> si riferisce in modo univoco a un'intestazione, che non è necessariamente un file. Le implementazioni sono praticamente gratuite per usare la sequenza di caratteri come desiderano. (Principalmente, tuttavia, basta trattarlo come un nome di file e fare una ricerca in percorso di inclusione , come affermano gli altri post.)
Se la #include "file"
viene utilizzato modulo, l'implementazione cerca innanzitutto un file con il nome specificato, se supportato. In caso contrario (supportato) o se la ricerca non riesce, l'implementazione si comporta come se #include <file>
fosse utilizzato l'altro modulo ( ).
Inoltre, esiste un terzo modulo che viene utilizzato quando la #include
direttiva non corrisponde a nessuno dei moduli sopra. In questa forma, alcuni preelaborazioni di base (come l'espansione macro) vengono eseguiti sugli "operandi" della #include
direttiva e il risultato dovrebbe corrispondere a una delle altre due forme.
<
e >
come chiave per indicizzarla nella libreria.
Alcune buone risposte qui fanno riferimento allo standard C ma hanno dimenticato lo standard POSIX, in particolare il comportamento specifico del comando c99 (es. Compilatore C) .
Secondo il numero 7 delle specifiche di base del gruppo aperto ,
-I directory
Modificare l'algoritmo per la ricerca di intestazioni i cui nomi non sono nomi di percorso assoluti da cercare nella directory denominata dal nome di percorso della directory prima di cercare nei soliti luoghi. Pertanto, le intestazioni i cui nomi sono racchiusi tra virgolette ("") devono essere ricercate prima nella directory del file con la riga #include , quindi nelle directory denominate nelle opzioni -I e infine nei soliti posti. Per le intestazioni i cui nomi sono racchiusi tra parentesi angolari ("<>"), l'intestazione deve essere cercata solo nelle directory denominate nelle opzioni -I e quindi nei normali luoghi. Directory denominate in -I opzioni devono essere ricercate nell'ordine specificato.invocazione del comando c99 .
Quindi, in un ambiente conforme a POSIX, con un compilatore C conforme a POSIX, #include "file.h"
è probabile che cercherà per ./file.h
primo, dove si .
trova la directory in cui si trova il file con l' #include
istruzione, mentre #include <file.h>
, è probabile che cercherà per /usr/include/file.h
prima, dove /usr/include
è definito il sistema luoghi abituali per le intestazioni (non sembra definito da POSIX).
c99
- che è il nome POSIX per il compilatore C. (Lo standard POSIX 2008 potrebbe a malapena fare riferimento a C11; l'aggiornamento del 2013 a POSIX 2008 non ha modificato lo standard C a cui si riferiva.)
-L
.
La documentazione GCC dice quanto segue sulla differenza tra i due:
Sia i file di intestazione utente che quelli di sistema sono inclusi usando la direttiva di preelaborazione
‘#include’
. Ha due varianti:
#include <file>
Questa variante viene utilizzata per i file di intestazione del sistema. Cerca un file denominato file in un elenco standard di directory di sistema. Puoi anteporre le directory a questo elenco con l'
-I
opzione (vedi Invocazione ).
#include "file"
Questa variante viene utilizzata per i file di intestazione del proprio programma. Cerca prima un file denominato file nella directory contenente il file corrente, quindi nelle directory delle quote e quindi nelle stesse directory utilizzate
<file>
. È possibile anteporre le directory all'elenco delle directory di preventivo con l'-iquote
opzione. L'argomento‘#include’
, delimitato da virgolette o parentesi angolari, si comporta come una costante di stringa in quanto i commenti non vengono riconosciuti e i nomi delle macro non vengono espansi. Pertanto,#include <x/*y>
specifica l'inclusione di un file di intestazione del sistema denominatox/*y
.Tuttavia, se si verificano barre rovesciate all'interno del file, vengono considerati normali caratteri di testo, non caratteri di escape. Nessuna delle sequenze di escape di caratteri appropriate alle costanti di stringa in C viene elaborata. Pertanto,
#include "x\n\\y"
specifica un nome file contenente tre barre rovesciate. (Alcuni sistemi interpretano "\" come un separatore di percorso. Tutti questi interpretano‘/’
allo stesso modo. È più portabile solo da usare‘/’
.)È un errore se c'è qualcosa (diverso dai commenti) sulla riga dopo il nome del file.
Fa:
"mypath/myfile" is short for ./mypath/myfile
con .
essendo o la directory del file in cui la #include
è contenuto in, e / o la directory di lavoro corrente del compilatore, e / o ladefault_include_paths
e
<mypath/myfile> is short for <defaultincludepaths>/mypath/myfile
Se ./
è dentro <default_include_paths>
, allora non fa differenza.
Se si mypath/myfile
trova in un'altra directory include, il comportamento non è definito.
#include "mypath/myfile"
non è equivalente a #include "./mypath/myfile"
. Come dice la risposta di piCookie, le doppie virgolette indicano al compilatore di cercare in un modo definito dall'implementazione, che include la ricerca nei luoghi specificati #include <...>
. (In realtà, probabilmente è equivalente, ma solo perché, per esempio, /usr/include/mypath/myfile
può essere indicato come /usr/include/./mypath/myfile
- almeno su sistemi simili a Unix.)
defaultincludepaths
, invece di dare un altro significato a .
(come indicato sopra). Ciò ha la conseguenza attesa che entrambi #include "..."
e la #include <...>
ricerca in dirpath
Il <file>
includono dice al preprocessore di cercare in -I
cartelle e nelle directory predefinite prima , poi nella directory del file .c. Il "file"
includono dice al preprocessore di cercare directory del file di origine prima , e poi tornare a -I
e predefiniti. Tutte le destinazioni vengono comunque ricercate, solo l'ordine di ricerca è diverso.
Lo standard del 2011 discute principalmente dei file di inclusione in "16.2 Inclusione dei file di origine".
2 Una direttiva di preelaborazione del modulo
# include <h-char-sequence> new-line
cerca una sequenza di posizioni definite dall'implementazione per un'intestazione identificata in modo univoco dalla sequenza specificata tra i delimitatori <e> e provoca la sostituzione di quella direttiva con l'intero contenuto dell'intestazione. Come vengono specificati i luoghi o identificato l'intestazione viene definita l'implementazione.
3 Una direttiva di preelaborazione del modulo
# include "q-char-sequence" new-line
provoca la sostituzione di tale direttiva con l'intero contenuto del file di origine identificato dalla sequenza specificata tra i "delimitatori. Il file di origine indicato viene cercato in modo definito dall'implementazione. Se questa ricerca non è supportata o se la ricerca non riesce , la direttiva viene rielaborata come se fosse stata letta
# include <h-char-sequence> new-line
con la stessa sequenza contenuta (compresi> eventuali caratteri) dalla direttiva originale.
Si noti che il "xxx"
modulo si degrada per <xxx>
formare se il file non viene trovato. Il resto è definito dall'implementazione.
-I
è specificata questa attività?
-I
.
#include <file.h>
dice al compilatore di cercare l'intestazione nella sua directory "include", ad es. per MinGW il compilatore cercherebbe file.h
in C: \ MinGW \ include \ o ovunque sia installato il compilatore.
#include "file"
indica al compilatore di cercare la directory corrente (ovvero la directory in cui risiede il file sorgente) file
.
Puoi usare il -I
flag per GCC per dirgli che, quando incontra un'inclusione con parentesi angolate, dovrebbe anche cercare le intestazioni nella directory dopo -I
. GCC tratterà la directory dopo il flag come se fosse la includes
directory.
Ad esempio, se hai un file chiamato myheader.h
nella tua directory, potresti dire #include <myheader.h>
se hai chiamato GCC con il flag -I .
(indicando che dovrebbe cercare le inclusioni nella directory corrente).
Senza il -I
flag, dovrai utilizzare #include "myheader.h"
per includere il file o passare myheader.h
alla include
directory del tuo compilatore.
Per lo standard - sì, sono diversi:
Una direttiva di preelaborazione del modulo
#include <h-char-sequence> new-line
ricerche una sequenza di luoghi di attuazione definite per un'intestazione identificato univocamente dalla sequenza specificata tra la
<
e>
delimitatori, e provoca la sostituzione di tale direttiva dall'intero contenuto dell'intestazione. Il modo in cui i luoghi vengono specificati o l'header identificato è definito dall'implementazione.Una direttiva di preelaborazione del modulo
#include "q-char-sequence" new-line
provoca la sostituzione di tale direttiva con l'intero contenuto del file sorgente identificato dalla sequenza specificata tra i
"
delimitatori. Il file di origine denominato viene cercato in un modo definito dall'implementazione. Se questa ricerca non è supportata o se la ricerca fallisce, la direttiva viene rielaborata come se fosse letta#include <h-char-sequence> new-line
con la stessa sequenza contenuta (inclusi eventuali
>
caratteri) dalla direttiva originale.Una direttiva di preelaborazione del modulo
#include pp-tokens new-line
(che non corrisponde a uno dei due moduli precedenti) è consentito. I token di preelaborazione successivi
include
nella direttiva vengono elaborati proprio come nel testo normale. (Ogni identificatore attualmente definito come nome di macro è sostituito dal suo elenco di token di preelaborazione di sostituzione.) La direttiva risultante dopo tutte le sostituzioni deve corrispondere a una delle due forme precedenti. Il metodo mediante il quale una sequenza di token di preelaborazione tra una<
e una>
coppia di token di preelaborazione o una coppia di"
caratteri viene combinata in un singolo token di preelaborazione del nome di intestazione è definito dall'implementazione.definizioni:
h-char: qualsiasi membro del set di caratteri di origine tranne il carattere di nuova riga e
>
q-char: qualsiasi membro del set di caratteri di origine tranne il carattere di nuova riga e
"
Si noti che lo standard non indica alcuna relazione tra i modi definiti dall'implementazione. Il primo modulo cerca in un modo definito dall'implementazione e l'altro in un modo (forse altro) definito dall'implementazione. La norma specifica inoltre che devono essere presenti alcuni file di inclusione (ad esempio <stdio.h>
).
Formalmente dovresti leggere il manuale del tuo compilatore, tuttavia normalmente (per tradizione) il #include "..."
modulo cerca nella directory del file in cui è #include
stato trovato prima il file, quindi nelle directory in cui #include <...>
cerca il modulo (il percorso include, ad esempio le intestazioni di sistema ).
Grazie per le ottime risposte, esp. Adam Stelmaszczyk e piCookie e aib.
Come molti programmatori, ho usato la convenzione informale di utilizzare il "myApp.hpp"
modulo per i file specifici dell'applicazione e il <libHeader.hpp>
modulo per i file di sistema della libreria e del compilatore, ovvero i file specificati in /I
e la INCLUDE
variabile di ambiente, per anni pensando che fosse lo standard.
Tuttavia, lo standard C afferma che l'ordine di ricerca è specifico dell'implementazione, il che può complicare la portabilità. A peggiorare le cose, usiamo jam, che individua automagicamente dove sono i file include. È possibile utilizzare percorsi relativi o assoluti per i file di inclusione. vale a dire
#include "../../MyProgDir/SourceDir1/someFile.hpp"
Le versioni precedenti di MSVS richiedevano doppie barre rovesciate (\\), ma ora non è necessario. Non so quando è cambiato. Basta usare le barre per la compatibilità con 'nix (Windows lo accetterà).
Se sei davvero preoccupato, usalo "./myHeader.h"
per un file di inclusione nella stessa directory del codice sorgente (il mio progetto attuale, molto grande ha alcuni duplicati di nomi di file sparsi, davvero un problema di gestione della configurazione).
Ecco la spiegazione MSDN copiata qui per comodità).
Modulo tra virgolette
Il preprocessore cerca i file di inclusione in questo ordine:
- Nella stessa directory del file che contiene l'istruzione #include.
- Nelle directory dei file attualmente aperti includere i file, nell'ordine inverso in cui
sono stati aperti. La ricerca inizia nella directory del file include parent e
continua verso l'alto attraverso le directory di tutti i file include nonni.- Lungo il percorso specificato da ciascuna
/I
opzione del compilatore.- Lungo i percorsi specificati dalla
INCLUDE
variabile d'ambiente.Forma a parentesi angolare
Il preprocessore cerca i file di inclusione in questo ordine:
- Lungo il percorso specificato da ciascuna
/I
opzione del compilatore.- Durante la compilazione si verifica sulla riga di comando, lungo i percorsi specificati dalla
INCLUDE
variabile di ambiente.
Almeno per la versione GCC <= 3.0, il modulo parentesi angolare non genera una dipendenza tra il file incluso e quello incluso.
Pertanto, se si desidera generare regole di dipendenza (utilizzando l'opzione GCC -M per esempio), è necessario utilizzare il modulo tra virgolette per i file che devono essere inclusi nell'albero delle dipendenze.
Per #include ""
un compilatore ricerche normalmente la cartella del file che contiene che includono e poi le altre cartelle. Per #include <>
il compilatore non cerca la cartella del file corrente.
<filename>
e "filename"
cerca luoghi definiti dall'implementazione.
Quando si utilizza #include <nomefile>, il pre-processore cerca il file nella directory dei file di intestazione C \ C ++ (stdio.h \ cstdio, stringa, vettore, ecc.). Ma quando usi #include "nomefile": prima di tutto, il pre-processore cerca il file nella directory corrente e, se non lo fa qui, lo cerca nella directory dei file di intestazione C \ C ++.
#include
direttiva non è affatto strettamente correlata ai file.
Un #include con parentesi angolari cercherà un "elenco di posizioni dipendente dall'implementazione" (che è un modo molto complicato di dire "intestazioni di sistema") per includere il file.
Un #include tra virgolette cercherà solo un file (e, "in modo dipendente dall'implementazione", bleh). Il che significa che, in inglese normale, proverà ad applicare il percorso / nome file che si lancia in esso e non anteporre un percorso di sistema o manometterlo in altro modo.
Inoltre, se #include "" fallisce, viene riletto come #include <> dallo standard.
La documentazione di gcc ha una descrizione (specifica del compilatore) che sebbene sia specifica per gcc e non lo standard, è molto più facile da capire rispetto al discorso in stile avvocato degli standard ISO.
zlib.h
percorsi di ricerca "utente" ed esiste una versione diversa nel percorso di ricerca del sistema, quindi #include <zlib.h>
include la versione del sistema e #include "zlib.h"
include la mia?
#include "filename" // User defined header
#include <filename> // Standard library header.
Esempio:
Il nome file qui è 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
Nell'implementazione della classe (ad esempio, Seller.cpp
e in altri file che utilizzeranno il file Seller.h
), l'intestazione definita dall'utente dovrebbe ora essere inclusa, come segue:
#include "Seller.h"
#include <>
è per file di intestazione predefinitiSe il file di intestazione è predefinito, devi semplicemente scrivere il nome del file di intestazione tra parentesi angolari e sembrerebbe così (supponendo che abbiamo un nome di file di intestazione predefinito iostream):
#include <iostream>
#include " "
è per i file di intestazione definiti dal programmatoreSe tu (il programmatore) hai scritto il tuo file header, dovresti scrivere il nome del file header tra virgolette. Supponiamo quindi che tu abbia scritto un file header chiamato myfile.h
, quindi questo è un esempio di come useresti la direttiva include per includere quel file:
#include "myfile.h"
Molte delle risposte qui si concentrano sui percorsi che il compilatore cercherà per trovare il file. Mentre questo è ciò che fanno la maggior parte dei compilatori, un compilatore conforme può essere preprogrammato con gli effetti delle intestazioni standard e trattare, diciamo,#include <list>
come un interruttore, e non deve necessariamente esistere come un file.
Questo non è puramente ipotetico. Esiste almeno un compilatore che funziona in questo modo. Si consiglia l'utilizzo #include <xxx>
solo con intestazioni standard.
#include <abc.h>
è usato per includere file di libreria standard. Quindi il compilatore verificherà le posizioni in cui risiedono le intestazioni di libreria standard.
#include "xyz.h"
dirà al compilatore di includere i file di intestazione definiti dall'utente. Quindi il compilatore controllerà questi file di intestazione nella cartella corrente o nelle -I
cartelle definite.
In C ++, includere un file in due modi:
Il primo è #include che dice al preprocessore di cercare il file nella posizione predefinita predefinita. Questa posizione è spesso una variabile d'ambiente INCLUDE che indica il percorso per includere i file.
E il secondo tipo è #include "nomefile" che dice al preprocessore di cercare prima il file nella directory corrente, quindi cercarlo nelle posizioni predefinite che l'utente ha impostato.
Innanzitutto, cerca la presenza del file di intestazione nella directory corrente da cui viene invocata la direttiva. Se non lo trova, cerca nell'elenco preconfigurato delle directory di sistema standard.
Questo cerca la presenza del file header nella directory corrente da cui viene invocata la direttiva.
L'elenco esatto della directory di ricerca dipende dal sistema di destinazione, dalla configurazione di GCC e da dove è installato. Puoi trovare l'elenco delle directory di ricerca del tuo compilatore GCC eseguendolo con l'opzione -v.
È possibile aggiungere ulteriori directory al percorso di ricerca utilizzando - I dir , che determina la ricerca di dir dopo la directory corrente (per il modulo di preventivo della direttiva) e prima delle directory di sistema standard.
Fondamentalmente, il modulo "xxx" non è altro che la ricerca nella directory corrente; se non trovato ricadendo nel modulo
#include "header.h"
modulo non è accurata, @personal_cloud. Ritengo che la risposta di piCookie e Yann Droneaud sia la più rilevante in quanto identificano la provenienza delle loro informazioni. Non trovo neanche la risposta più votata del tutto soddisfacente.
La #include <filename>
si usa quando un file di sistema è stato denominato. Questo è un file di intestazione che può essere trovato nelle posizioni predefinite del sistema come /usr/include
o /usr/local/include
. Per i tuoi file che devono essere inclusi in un altro programma devi usare la #include "filename"
sintassi.
il "<nome file>" cerca in posizioni di libreria C standard
mentre "nomefile" cerca anche nella directory corrente.
Idealmente, useresti <...> per le librerie C standard e "..." per le librerie che scrivi e che sono presenti nella directory corrente.
La semplice regola generale è utilizzare parentesi angolate per includere i file di intestazione forniti con il compilatore. Utilizzare le virgolette doppie per includere qualsiasi altro file di intestazione. La maggior parte dei compilatori lo fa in questo modo.
1.9 - I file di intestazione spiegano in modo più dettagliato le direttive pre-processore. Se sei un programmatore principiante, quella pagina dovrebbe aiutarti a capire tutto ciò. L'ho imparato da qui e l'ho seguito al lavoro.
#include <filename>
viene utilizzato quando si desidera utilizzare il file di intestazione del sistema C / C ++ o le librerie del compilatore. Queste librerie possono essere stdio.h, string.h, math.h, ecc.
#include "path-to-file/filename"
viene utilizzato quando si desidera utilizzare il proprio file di intestazione personalizzato che si trova nella cartella del progetto o da qualche altra parte.
Per ulteriori informazioni su preprocessori e intestazione. Leggi C - Preprocessori .
#include <filename>
#include "filename"
#include <filename>
e cerca quel file di intestazione nel punto in cui sono memorizzati i file di intestazione del sistema.#include <filename>
.Per vedere l'ordine di ricerca sul tuo sistema usando gcc, basato sulla configurazione corrente, puoi eseguire il seguente comando. Puoi trovare maggiori dettagli su questo comando qui
cpp -v /dev/null -o /dev/null
Apple LLVM versione 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin18.0.0
Modello discussione: posix InstalledDir: Library / Developer / CommandLineTools / usr / bin
"/ Library / Developer / CommandLineTools / usr / bin / clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-use -Werror = deprecated-objc-isa-use -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 versione 10.0.0 (clang-1000.10.44.2) target predefinito x86_64-apple-darwin18.0.0 ignorando la directory inesistente "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/local/include" ignoring inexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." la ricerca inizia qui:
#include <...> la ricerca inizia qui:
/ usr / local / include
/ Libreria / Sviluppatore / 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 / Sistema / Libreria / Frameworks (directory framework)
Fine dell'elenco di ricerca.
Esistono due modi per scrivere l'istruzione #include: questi sono:
#include"filename"
#include<filename>
Il significato di ogni forma è
#include"mylib.h"
Questo comando cercherebbe il file mylib.h
nella directory corrente e l'elenco specificato delle directory come menzionato nel percorso di ricerca include che potrebbe essere stato impostato.
#include<mylib.h>
Questo comando cercherebbe il file mylib.h
solo nell'elenco di directory specificato.
Il percorso di ricerca include non è altro che un elenco di directory che verrebbero ricercate per il file incluso. Diversi compilatori C consentono di impostare il percorso di ricerca in modi diversi.