問題描述
我最近有理由使用通常的調試和發布配置以及我以前從未見過的全部發布"和全部調試"來處理一些 Visual Studio C++ 項目.
I recently had cause to work with some Visual Studio C++ projects with the usual Debug and Release configurations, but also 'Release All' and 'Debug All', which I had never seen before.
事實證明，項目的作者有一個 ALL.cpp，其中 #includes 所有其他 .cpp 文件.*All 配置只是構建這個 ALL.cpp 文件.它當然被排除在常規配置之外，常規配置不構建ALL.cpp
It turns out the author of the projects has a single ALL.cpp which #includes all other .cpp files. The *All configurations just build this one ALL.cpp file. It is of course excluded from the regular configurations, and regular configurations don't build ALL.cpp
我只是想知道這是否是一種常見做法?它帶來什么好處?(我的第一反應是它聞起來很糟糕.)
I just wondered if this was a common practice? What benefits does it bring? (My first reaction was that it smelled bad.)
您可能會遇到哪些陷阱?我能想到的一個問題是，如果您的 .cpps 中有匿名命名空間，它們不再是該 cpp 的私有"名稱，但現在在其他 cpp 中也可見?
What kinds of pitfalls are you likely to encounter with this? One I can think of is if you have anonymous namespaces in your .cpps, they're no longer 'private' to that cpp but now visible in other cpps as well?
所有項目都構建 DLL，所以在匿名命名空間中保存數據不是一個好主意，對吧?但是功能就可以了嗎?
All the projects build DLLs, so having data in anonymous namespaces wouldn't be a good idea, right? But functions would be OK?
推薦答案
它被一些人(和 google-able)稱為Unity Build".它的鏈接速度非?？?，編譯速度也相當快.它非常適合您不需要迭代的構建，例如來自中央服務器的發布構建，但不一定適用于增量構建.
It's referred to by some (and google-able) as a "Unity Build". It links insanely fast and compiles reasonably quickly as well. It's great for builds you don't need to iterate on, like a release build from a central server, but it isn't necessarily for incremental building.
這是一個需要維護的 PITA.
And it's a PITA to maintain.
這是獲取更多信息的第一個谷歌鏈接:http://buffered.io/posts/the-magic-of-unity-builds/
here's the first google link for more info: http://buffered.io/posts/the-magic-of-unity-builds/
使其快速的原因是編譯器只需要讀入所有內容，編譯出來，然后鏈接，而不是對每個 .cpp 文件都這樣做.
The thing that makes it fast is that the compiler only needs to read in everything once, compile out, then link, rather than doing that for every .cpp file.
Bruce Dawson 在他的博客上寫得更好:http://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/
Bruce Dawson has a much better write up about this on his blog: http://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/
這篇關于#include 所有 .cpp 文件到一個編譯單元?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！