減少cpp翻譯單元的數量是一個好主意嗎？

Question

我發現如果有很多類，當我每個類使用一個* .h和一個* .cpp文件時，編譯時間會大大增加。 我已經使用預編譯頭和增量鏈接，但編譯時間仍然很長（是的，我使用boost;）

所以我想出了以下技巧：

• 將* .cpp文件定義為不可編譯
• 將* .cxx文件定義為可編譯
• 每個應用程序模塊添加一個* .cxx文件，＃include此模塊的所有* .cpp文件。

因此，我只有8個翻譯單元，而不是100多個翻譯單元。 編譯時間縮短了4-5倍。

缺點是您必須手動包含所有* .cpp文件（但它不是真正的維護噩夢，因為如果您忘記包含鏈接器將提醒您的內容），並且某些VS IDE便利不適用於此方案，例如轉到/轉移到實施等

所以問題是，有很多cpp翻譯單元真的是唯一真正的方法嗎？ 我的伎倆是一種已知的模式，還是我錯過了什么？ 謝謝！

Answer 1

這種方法的一個顯着缺點是由於每個翻譯單元有一個.obj文件。

如果您創建一個靜態庫以便在其他項目中重用，那么如果您有幾個巨大的翻譯單元而不是許多小翻譯單元，那么您將經常在這些項目中面對更大的二進制文件，因為鏈接器將只包含.obj文件，其中包含真正引用的函數/變量在使用該庫的項目中。

在大型翻譯單元的情況下，更有可能引用每個單元並包含相應的.obj文件。 在某些情況下，更大的二進制文件可能是一個問題。 一些鏈接器也足夠聰明，只能包含必要的函數/變量，而不是整個.obj文件。

此外，如果包含.obj文件並且包含所有全局變量，則在程序啟動/停止時將調用它們的構造函數/析構函數，這肯定需要時間。

Answer 2

我已經看到你在視頻游戲中做了什么，因為它有助於編譯器進行優化，否則無法做到以及節省大量內存。 我見過“超級構建”和“批量構建”是指這個想法。 如果它有助於加速你的構建，為什么不..

Answer 3

將大量C ++源代碼文件捆綁到一個文件中是最近幾次提到過的一種方法，特別是當人們構建大型系統並引入復雜的頭文件時（那將是提升）。

當你提到VS時，我發現項目中包含文件的數量，特別是include路徑的大小，似乎影響了Visual C ++的編譯時間，遠遠超過了g ++的編譯時間。 特別是大量嵌套包含的情況（再次，boost會這樣做），因為需要大量的文件搜索才能找到源代碼所需的所有包含文件。 將代碼組合到單個源文件中意味着編譯器可以更加智能地查找所述包含，並且顯然更少找到它們，因為您可能期望同一子項目中的文件可能包含非常相似頭文件集。

C ++開發的“大量編譯單元​​”方法通常來自於要求解耦類和最小化類之間的依賴關系，因此編譯器只需重建最小的文件集，以防您進行任何更改。 這通常是一種很好的方法，但在子項目中通常不太可行，因為那里的文件之間存在依賴關系，所以無論如何你最終都會進行大規模的重建。

Answer 4

我不認為減少編譯單元的數量是一個好主意。 你正試圖用大的編譯時間解決問題，這種方法似乎有助於它，但你得到的另外：

1. 在開發期間增加編譯時間。 通常開發人員一次修改幾個文件，對於3-4個小文件然后對於一個非常大的文件，編譯可能會更快。
2. 正如你所提到的，更難以導航代碼，恕我直言這是非常重要的。

3. 您可以在一個.cxx文件中包含的.cpp文件之間產生一些干擾：

   一個。 通常的做法是在cpp文件中本地定義（用於調試版本）宏新的內存泄漏檢查。 不幸的是，在使用placement new包含頭文件之前無法做到這一點（如某些STL和BOOST頭部那樣）

   灣 通常的做法是在cpp文件中添加聲明。 使用您的方法，這可能會導致標題出現問題，稍后會包含在內

   C。 名稱沖突更可能發生

恕我直言，更加清潔（但可能更昂貴的方式）加快編譯時間是使用一些分布式構建系統。 它們對於清潔構建尤其有效。

Answer 5

我不確定這是否與您的情況相關，但也許您可以使用聲明而不是定義來減少您必須執行的#include的數量。 此外，也許你可以使用pimpl習語來達到同樣的目的。 這有望減少每次需要重新編譯的源文件數量以及必須提取的標頭數量。

Answer 6

更大和更少的翻譯單元不利用並行編譯。 我不知道你使用的編譯器和平台是什么，但並行編譯多個翻譯單元可能會大大減少構建時間......

Answer 7

這個概念被稱為統一構建

Answer 8

從sharptooths帖子開始，我傾向於詳細檢查結果可執行文件。 如果它們不同，我傾向於限制您的技術來調試構建並使用主要版本構建的原始項目配置。 檢查可執行文件時，我還會查看啟動時和運行時的內存占用和資源使用情況。