On Tue, Feb 14, 2017 at 11:28 AM, Jeff Coffler <jeff.coff...@microsoft.com.invalid> wrote: > For efficiency purposes, if a header file is included by 50% or more of the > source files, it should be included in the precompiled header. If a header is > included in fewer than 50% of the source files, then it can be separately > included (and thus would not benefit from precompiled headers). Note that > this is a guideline; even if a header is used by less than 50% of source > files, if it's very large, we still may decide to throw it in the precompiled > header.
It seems like this would have the effect of creating many false dependencies: if file X doesn't currently include header Y but Y is included in the precompiled header, the symbols in Y will now be visible when X is compiled. It would also mean that X would need to be recompiled when Y changes. Related: the current policy is that headers and implementation files should try to include all of their dependencies, without relying on transitive includes. For example, if foo.cpp includes bar.hpp, which includes <vector>, but foo.cpp also uses <vector>, both foo.cpp and bar.hpp should "#include <vector>". Adopting precompiled headers would mean making an exception to this policy, right? I wonder if we should instead use headers like: <- mesos_common.h -> #include <a> #include <b> #include <c> <- xyz.cpp, which needs headers "b" and "d" -> #include "mesos_common.h> #include <b> #include <d> That way, the fact that "xyz.cpp" logically depends on <b> (but not <a> or <c>) is not obscured (in other words, Mesos should continue to compile if 'mesos_common.h' is replaced with an empty file). Does anyone know whether the header guard in <b> _should_ make the repeated inclusion of <b> relatively cheap? Neil
