圖書館不是隻有標題的原因是什麼？

我真的很喜歡使用僅頭文件的庫，因爲它們非常易於使用（無需鏈接器問題或需要單獨編譯庫）。例如，大多數Boost庫僅用於標題。但是，然後又有一些部分，比如boost :: python，它需要在之前構建。這是設計選擇還是技術需要？圖書館不是隻有標題的原因是什麼？

我以Boost爲例，但如果可能的話，我會讚賞更普遍的答案。

來源

2016-01-20 NOhs

減少編譯時間，因爲您可以鏈接到預編譯庫。對於僅包含頭文件的庫，您必須每次都使用代碼編譯庫，這會大大增加編譯時間。 – Banan

是的，每次使用boost時，編譯時間都會增加很多。每次在其中包含實現的模板時，在每個c/cpp文件中，編譯器都會重新解釋實現。當您從源代碼編譯Google-Chrome時，首次需要大約24小時的編譯，請想象僅在標題中使用模板。 –

當實現所需的頭文件時，在全局名稱空間中引入了許多醜陋的宏和名稱，最簡單的隔離方法是僅將其包含在單獨的翻譯單元中。這就是所謂的**編譯器防火牆**，又名「柴郡貓」（我不知道爲什麼）。另一種方法是重新聲明東西，例如一個Windows API函數，但總的來說可以是非常多的工作，並且可以引入一個不錯的版本依賴性。 –

使用編譯庫的最初原因是爲了節省編譯時間。圖書館可能很大。他們可以是巨大的。

另一個說法是他們保持源代碼分開。還有很多不是開源的宇宙。

來源

2016-01-20 11:22:54

贊成只有標題的：

更少的時間來建立/進口
沒有連接的麻煩

只針對標題：標題無法解決的與之間

碰撞它們之間的編譯時防火牆
沒有依賴隱藏可能
增加每個目標的編譯時間，包括其標頭
添加到從目標導出的符號堆。您的簡單測試文件現在可能會導出幾千個符號。
（在極端情況下）可能會減少COMDAT可摺疊符號之間的分隔，導致符號的多個副本無法從目標輸出文件中移除，從而導致膨脹。這應該只發生在ELF上的32k +符號上，但是在其他目標（比如Mach-O）上發生的時間要早得多。

來源

2016-01-20 11:59:17 dascandy

除信息隱藏外，所有問題都是由於原始工具造成的。但是信息隱藏/編譯器防火牆是一個真正的問題。因此，我們等待，然後等待，等待，等待模塊，例如Daveed的。 –

圖書館不是隻有標題的原因是什麼？

回答

相關問題