#include 所有 .cpp 文件到一個編譯單元？

Question

想改進這篇文章嗎？ 提供此問題的詳細答案，包括引文和解釋為什么您的答案是正確的。 沒有足夠詳細信息的答案可能會被編輯或刪除。

我最近有理由使用一些帶有通常調試和發布配置的 Visual Studio C++ 項目，還有我以前從未見過的“全部發布”和“全部調試”。

事實證明，項目的作者有一個 ALL.cpp，其中 #includes 所有其他 .cpp 文件。 *All 配置只是構建這個 ALL.cpp 文件。 它當然被排除在常規配置之外，常規配置不構建ALL.cpp

我只是想知道這是否是一種常見做法？ 它帶來什么好處？ （我的第一反應是它聞起來很糟糕。）

您可能會遇到哪些陷阱？ 我能想到的一個問題是，如果您的 .cpps 中有匿名命名空間，它們不再是該 cpp 的“私有”名稱，但現在在其他 cpp 中也可見？

所有項目都構建 DLL，所以在匿名命名空間中保存數據不是一個好主意，對吧？ 但是功能就可以了嗎？

Answer 1

它被一些（和 google-able）稱為“Unity Build”。 它的鏈接速度非常快，編譯速度也相當快。 它非常適合您不需要迭代的構建，例如來自中央服務器的發布構建，但不一定適用於增量構建。

這是一個需要維護的 PITA。

編輯：這里是更多信息的第一個谷歌鏈接： http : //buffered.io/posts/the-magic-of-unity-builds/

使它快速的事情是編譯器只需要讀入一次，編譯出來，然后鏈接，而不是對每個 .cpp 文件都這樣做。

布魯斯·道森 (Bruce Dawson) 在他的博客上對此進行了更好的描述： http : //randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/

Answer 2

Unity 構建改進的構建速度主要有以下三個原因。 第一個原因是所有共享頭文件只需要解析一次。 許多 C++ 項目有很多頭文件，大多數或所有 CPP 文件都包含這些頭文件，而這些的冗余解析是編譯的主要成本，尤其是當您有許多短源文件時。 預編譯頭文件可以幫助解決這個成本，但通常有很多未預編譯的頭文件。

統一構建提高構建速度的下一個主要原因是編譯器被調用的次數更少。 調用編譯器會產生一些啟動成本。

最后，冗余頭解析的減少意味着內聯函數的冗余代碼生成減少，因此目標文件的總大小更小，這使得鏈接更快。

Unity 構建還可以提供更好的代碼生成。

由於磁盤 I/O 減少，Unity 構建速度並不快。 我已經使用 xperf 分析了許多構建，我知道我在說什么。 如果您有足夠的內存，那么 OS 磁盤緩存將避免冗余 I/O - 標頭的后續讀取將來自 OS 磁盤緩存。 如果您沒有足夠的內存，那么統一構建甚至可能導致編譯器的內存占用超過可用內存並被分頁，從而使構建時間變得更糟。

磁盤 I/O 很昂貴，這就是所有操作系統積極緩存數據以避免冗余磁盤 I/O 的原因。

Answer 3

我想知道 ALL.cpp 是否試圖將整個項目放在一個編譯單元中，以提高編譯器優化程序大小的能力？

通常，某些優化僅在不同的編譯單元中執行，例如刪除重復代碼和內聯。

也就是說，我似乎記得最近的編譯器（微軟的，英特爾的，但我認為這不包括 GCC）可以跨多個編譯單元進行這種優化，所以我懷疑這個“技巧”是不必要的。

也就是說，很好奇是否確實存在任何差異。

Answer 4

我同意布魯斯的觀點； 根據我的經驗，我曾嘗試為我的一個 .dll 項目實施 Unity Build，該項目包含大量標頭和大量 .cpp； 為了減少 VS2010 上的整體編譯時間（已經用完了增量構建選項），但沒有減少編譯時間，我用完了內存，構建甚至無法完成編譯。

但是要補充; 我確實發現在 Visual Studio 中啟用多處理器編譯選項非常有助於減少編譯時間； 我不確定在其他平台編譯器中是否可以使用這樣的選項。

Answer 5

除了 Bruce Dawson 的出色回答之外，以下鏈接還提供了有關統一構建優缺點的更多見解 - https://github.com/onqtam/ucm#unity-builds

Answer 6

我們有一個適用於 MacOS 和 Windows 的多平台項目。 我們有許多大型模板和許多標題要包含在內。 我們使用預編譯頭文件使用 Visual Studio 2017 msvc 將構建時間減半。 對於 MacOS，我們嘗試了幾天來減少構建時間，但預編譯頭文件僅將構建時間縮短到 85%。 使用單個 .cpp 文件是一個突破。 我們只需使用腳本創建這個 ALL.cpp。 我們的 ALL.cpp 包含我們項目的所有 .cpp 文件的包含列表。 我們使用 XCode 9.0 將構建時間減少到 30%。 唯一的缺點是我們必須為 .cpp-Files 中的所有私有未命名編譯單元命名空間命名。 否則本地名稱會發生​​沖突。