DO NOT rely on the headers that are included in your precompiled header to "clear the code" by removing these headers from other source files. This creates a nightmare if you ever want to stop using PCH. You always want your dependencies to be explicit in every source file. Just turn them on in both places - there is no harm (provided that you have suitable guards in place).
A header file that is included in several source files is a good candidate for inclusion in PCH (especially if it is long). I believe that I am not taking the advice too seriously to use only headers that rarely change in PCH. But it depends on your overall project structure. If you often complete a complete build, be sure to avoid this tip. If you want to minimize work in incremental rebuilds, then this will be considered. In my experience, PCH recovery is relatively fast, and the cost of this far exceeds the overall compilation acceleration in general (in most cases). I'm not sure that all PCH systems are smart enough to understand that each source file does not need to be rebuilt when the header is included in the PCH changes (VC ++ is), but explicitly #include contains everything you need in each translation unit will certainly make this easier (another reason you should not rely on what's included in your PCH)
If your compiler supports the option to display the #include tree for each file at compile time, this can be a big help to determine the headers that should be included in PCH (those that are most manifest). I recently went through a project that I am working on (which has already used PCH, but not optimally), and accelerated the assembly of 750K C ++ lines from about 1.5 hours to 15 minutes.
user123456
source share