include尖括號和雙引號的對話[轉錄]

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: 嗯, 看來搜尋路徑列表是基於編譯器工作路徑的.