所謂標頭檔案發布，就是在build某個工程的build過程中，把頭檔案發布到特定的輸出目錄，而依賴於此工程的**，則需要從此特定的輸出目錄來include標頭檔案。換句話說，在這種做法下，標頭檔案與最終產生的library/binary具有同等地位，它也是build過程的乙個產出。
我們寫c++**，一般都是直接從source目錄包含所需要的標頭檔案的，那麼為什麼要使用這種標頭檔案發布的方式呢？ 我們可以先分析一下不發布標頭檔案可能帶來的問題：
因為直接從source目錄包含標頭檔案，我們無法控制哪些標頭檔案可以include，而哪些不可以。因為很多情況下，我們很可能只想對使用者暴露某個層次的api，但對於使用者來說，因為他們在同一目錄下，包含任何標頭檔案都是同等方便的。這明顯提高了犯錯的可能性。
如果build不完整，有些問題要到鏈結時才能發現。
舉個例子，如果a依賴於b，你在b中新增加了個函式，在a中使用。然後你在沒有build b的情況下直接build了a，這個錯誤無法在編譯期檢測出來，而只有把所有原始檔編譯完了鏈結的時候你才被通知有這麼個錯誤，對於大工程，這會是個問題。
如果build不完整，有些問題在執行時才能發現 - 這就是bug了
舉個例子，還是a依賴於b，你在b中修改了乙個巨集定義或者常量定義，如把#define pi 3.14改成了#define pi 3.1415926，然後你又忘了build b而直接去build a了，此時編譯沒有問題，但是此時模組b與模組a中對pi的定義就不一致了，必然會造成執行時問題，這種問題要更難發現。
所以，為了保證c++**中介面與binary的完全統一，包括可見性與行為上的統一，使用標頭檔案發布是非常有效的乙個方法，對於上述問題：
通過只把需要暴露的標頭檔案發布到特定目錄，有效的杜絕了使用者」包含不該包含「的標頭檔案的問題
因為b中被更新的標頭檔案未被發布，該問題被提前到編譯期被發現
因為b中被更新的標頭檔案未被發布，此時a與b的binary中使用的pi，都是未更新的3.14，從而保證了一致性。
要實現標頭檔案發布，其實也蠻簡單，主要是編譯設定上的事，對源**並沒有影響：
為方便說明，還是用a依賴於b為例：
如果你用visual studio的話，可以用post build event；用gmake的話，可以新加乙個publish header的rule。
C 中的標頭檔案
通常每乙個.cpp檔案都有乙個對應的.h檔案，但是也有例外如main函式所在的.cpp檔案。c 標準庫中除了定義c 語言特有的功能外，還相容了c語言的標準庫。c語言的標頭檔案形如 name.h，而c 中將這些檔案命名為cname，去掉了.h字尾，在前面新增了字母c，c的含義表示這是乙個屬於c語言標準...
C 中的標頭檔案
標頭檔案的字尾在c 的不同實現中是不同，所以標準c 也沒指定標頭檔案字尾，c 的標頭檔案包含一般不指明字尾，例如 include 而在c語言中.h是指定的標頭檔案字尾 如果你直接 include 將直接應用c的標頭檔案庫的指定檔案，這個時候你可以直接使用對應的檔案中的函式等，而如果使用了 inclu...
c 中的標頭檔案
c 中的標頭檔案裡面包含的是某個庫的外部宣告函式或者變數。因此為了宣告庫中已有的函式和變數，程式中只要包含標頭檔案即可。引入標頭檔案，要使用 include預處理器命令。預處理器是乙個程式，它用定義好的模式代替源 中的模式，這發生在編譯之前。也就是說，在編譯之前，預處理器會將指定的標頭檔案開啟，然後...