Actually, this is a policy I have never been a big fan of. In my experience 
just forward declaring as much as possible in the headers and only including in 
compilations units tend to have decent improvements in complication time, 
particularly files like `mesos.cpp` or `slave.cpp` which indirectly end up 
including almost every header in the project.

Alexander Rojas
alexan...@mesosphere.io




> On 15 Feb 2017, at 20:12, Neil Conway <neil.con...@gmail.com> wrote:
> 
> 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

Reply via email to