每個源文件頭文件

Question

我想了解每個源文件方法的一個頭文件背後的用途。正如我所看到的，頭文件是用於共享函數聲明，typedef的和使用它們的幾個文件之間的宏。當你爲你的.c文件創建一個頭文件時，它的缺點是每次你想看到一個函數聲明或者宏時，你都需要引用頭文件，通常情況下，一切都在一個源文件中（而不是整個軟件當然）。

那麼爲什麼程序員使用這種方法呢？

Answer 1

C定義中的頭文件（必須位於一個地方）中的C個單獨聲明（必須可用於每個使用函數的.c文件）。此外，它們提供了一點模塊性，因爲您只能將公共接口放入頭文件中，而不會提及應該在.c文件內部的函數和靜態變量。這使用文件系統來提供公共接口和私有實現。

一個.h文件對一個.c文件的練習大多是方便的。那樣的話，你知道這些聲明在。h文件以及相應的.c文件中的定義。

Answer 2

通常，源文件方法的頭文件意味着您只聲明該頭文件中該編譯單元的函數。

這樣你就不會污染你不需要的聲明。 （在大型軟件項目中可能會出現問題）

對於單獨的編譯單元，這些編譯單元加速了編譯，並且可以幫助您避免在私有符號聲明爲靜態時發生衝突。

Answer 3

每個源文件不需要一個頭文件。每個模塊一個頭文件，包含公共接口，並且可能在該模塊中的文件之間共享包含私有聲明等的額外頭文件。

Answer 4

因爲，如你所說，將「整個軟件」放入一個源文件是不可行的。

如果你的程序非常小，那麼是的，只是把所有東西放在一個.c文件中就簡單了。隨着程序變得越來越大，通過將相關函數放在不同的.c文件中組織起來會變得很有幫助。此外，在.h文件中，您可以限制您爲聲明應爲以供其他.c文件中的內容使用的聲明。如果一個.c文件不包含任何應該可以在其外部訪問的內容，它不需要標題。例如，如果.c具有函數foo（）和fooHelper（），但除了foo（）之外沒有人直接調用fooHelper（），那麼通過將foo（）和fooHelper（）放入foo.c中，只將foo（）的聲明放在foo.h中，並將fooHelper（）聲明爲靜態，這有助於強制程序的其他部分只應訪問foo（），而不應該知道或關心fooHelper（）。一種非面向對象的封裝形式。

最後，make引擎一般都足夠聰明，可以重建自上一次構建以來發生更改的文件，因此可以分割成多個.c文件（使用.h文件共享需要共享的文件）有助於加速構建。

Answer 5

您只能將頭文件放在其他源文件需要「看」才能編譯的最低限度。我已經看到一些人將所有非代碼放入頭文件（所有typedef，所有#define，所有結構等），即使代碼庫中沒有其他人會使用這些代碼。這使得頭文件很難爲自己和那些想要使用你的模塊的人閱讀。

Answer 6

邏輯，結構化的組織和小源文件使：

• 更快，更好的編程 - 將代碼分成更易於管理和理解的塊使得它更容易找到，理解和編輯相關的代碼。
• 代碼重用性 - 代碼的不同「模塊」可以分成多組源/頭文件，您可以更輕鬆地將它們集成到不同的程序中。
• 更好的「封裝」 - 只有專門包含該頭文件的.c文件才能使用它的功能，這有助於最大限度地減少代碼不同部分之間的關​​系，從而有助於實現模塊化。它不會阻止你使用任何地方的東西，但它可以幫助你思考爲什麼特定的c文件需要訪問在特定頭文件中聲明的函數。
• 艾滋病團隊合作 - 兩位試圖同時更改相同代碼文件的程序員通常會導致問題（例如排他鎖）或額外工作（例如代碼合併），從而導致對方速度慢下來。
• 更快編譯 - 如果您有一個標題，那麼每當您對其進行更改時，您必須重新編譯所有內容。對於許多小標題，只有包含更改標題的.c文件必須重建。
• 更容易維護&重構 - 上述所有原因

特別是「爲每個源文件一個標題」使得它很容易找到有關你工作的C文件中的聲明。只要您開始將多個頭文件合併到一個文件中，就很難將c和h文件關聯起來，最終使構建大型應用程序變得更加困難。如果您只是在一個小型應用程序上工作，那麼養成使用可擴展方法的習慣仍然是一個好主意。

Answer 7

程序員使用這個方法，因爲它允許他們從實施分離界面而低保客戶端代碼和執行的功能的聲明一致。 .h文件是關於每個函數原型的「單一事實點」（請參閱​​不要重複自己）。

（客戶端代碼的代碼#include的才能使用導出的函數.h文件，但在.H未實現任何功能。）