標籤:
A: #include "..." 和 #include <...> 有什麼區別?
B: 他喵的, 這麼簡單的問題. 角括弧是先在系統目錄下找, 雙引號是首先在目前的目錄下找, 找不到就找系統目錄.
A: 說得很含糊. 那麼我問你, 目前的目錄有個叫hdr.h的檔案,
目前的目錄下還有一個子目錄sub, sub裡面有兩個檔案hdr.h和1.c,
1.c中#include "hdr.h",
那麼在目前的目錄編譯sub/1.c, 它應該包含哪一個hdr.h?
bash-3.2$ tree |-- sub | |-- 1.c | `-- hdr.h `-- hdr.h bash-3.2$ cat sub/1.c #include "hdr.h" bash-3.2$ gcc -c sub/1.c
B: 應該包含外面的hdr.h吧, 因為它在gcc工作的目前的目錄, 而子目錄的hdr.h不在目前的目錄, 應該搜不到.
A: 錯, 包含的是sub/hdr.h !
B: 啊!... 喔... 雙引號是首先在使用include的源檔案所在目錄找(也就是1.c所在的目錄sub找), 而不是編譯器當前工作目錄找, 我原來理解錯了.
A: 是的, gcc和msvc的include雙引號都是先在使用include的源檔案所在目錄找.
B: C99標準是怎麼規定的? 是源檔案目前的目錄還是編譯器工作目錄?
A: 其實C99標準沒有規定#include "..." 先找哪個目錄, 只說取決於實現, 你可以設計一個C編譯器include雙引號時按你設計的方式找(如果找不到退化為#include <...>). 但事實上的工業標準是"雙引號優先從使用include的源檔案所在目錄".
B: 明白了.
A: 那麼我再問你, #include <...> 所謂的"從系統目錄找", 那麼"系統目錄"到底有哪些, 怎麼看呢?
B: 編譯時間-I指定的目錄唄.
A: 如果沒指定-I的參數時, 是不是系統目錄列表就是空的?
B: 當然不是, 有預設的吧.
A: 怎麼看預設的?
B: 這個不知道. 怎麼看?
A: 以gcc為例, 在命令列運行 echo | gcc -E -v -
bash-3.2$ echo | gcc -E -v - * * * #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-pc-linux-gnu/4.8.2/include /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.8.2/include-fixed /usr/include End of search list.
B: 那麼我指定gcc -I. 時是把 . 作為搜尋路徑還是把目前的目錄轉成絕對路徑加入到列表中呢?
A: 這個問題問得好! 其實我也不知道, 要不我們試一下.
bash-3.2$ echo | gcc -E -v -I. - * * * #include "..." search starts here: #include <...> search starts here: . /usr/lib/gcc/i686-pc-linux-gnu/4.8.2/include /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.8.2/include-fixed /usr/include End of search list.
B: 並沒有轉成絕對路徑, 就是一個點.
A: 恩, 那麼問題來了, 下面這種情形下( 注意: 1.c的內容修改為 #include <hdr.h> ), 會包含那個hdr.h ?
bash-3.2$ tree |-- sub | |-- 1.c | `-- hdr.h `-- hdr.h bash-3.2$ cat sub/1.c #include <hdr.h> bash-3.2$ gcc -c -I. sub/1.c
B: 我猜會用子目錄的hdr.h.
A: 我猜會用外層的hdr.h,
在hdr.h寫個1,
在sub/hdr.h寫個2,
然後 gcc -E -I. sub/1.c.
你看結果是1, 我猜對了!
B: 嗯, 看來搜尋路徑列表是基於編譯器工作路徑的.
關於C語言include角括弧和雙引號的對話