How to use stdafx.h properly?

Question

What is the proper way to use stdafx.h, in terms of separating dependencies?

If I put everything in there, then my compiles are blazing fast, and all I need to say in any file is

#include "stdafx.h"

with the caveats that:

1. I no longer know which files depend on which headers.
2. It reduces modularity, making my code less reusable.
3. I can no longer separate C #includes from C++ ones (e.g. cstring versus string.h) without a great deal of pain. (Speaking of which, does this even matter?)

If I put nothing in there, I can organize everything well -- but then my compiles slow down dramatically.

If I put everything in there and also include every header in my individual files, then I get the best of both worlds, with the caveat that now I have to keep track of synchronization issues.

Is there a well-known/well-accepted solution to this problem?

Beall

Answer 1

You shouldn't put your own header files in stdafx.h since your code is likely to change and will cause your whole program to recompile.

I usually put standard headers and other libraries in there, such as all boost includes.

Ellga

Agreed. Put things in precompiled headers that you aren't going to be touching within the scope of that project. – Hendecasyllable

I'm not sure how this is relevant. I still won't know which of my source files depend on which headers (did I really need to #include <windows.h> indirectly in every file?), even if they're system headers. And so it will still be non-modular. – Beall

@Mehrdad, that is one of the compromises of having a precompiled header. – Ellga

@Marlon: You don't seem to be answering my question unfortunately. :( Would you mind re-reading it? The answer currently doesn't tell me anything regarding the caveats I mentioned. – Beall

@Mehrdad: Write your code without PCH. Then add most used external headers into PCH. There are no issues, precompiled headers are purely an optimisation. – Alleyn

@Cat: "Write your code without PCH" --> this doesn't make much sense to me, because the whole point of PCH is to help you while writing/debugging your code! If you've already written it then there's nothing to optimize, really. The question is, do I also #include everything in my own headers or not? – Beall

@Mehrdad: I've already said it about three times. Yes, you do. With the usual rules of minimising the dependencies between headers (so more includes in the implementation files, less in the headers themselves). – Alleyn

@Cat: So that means I'm duplicating every single #include at least once? Doesn't that make additions/removals more error-prone? – Beall

@Mehrdad: First of all, you don't put every header in there, only ones that make a difference. Second of all, it's an optimisation, i.e. your code should compile whether it is there, or not. PCH ideally should never change, or change very rarely (and the same goes for whatever is included from the PCH). – Alleyn

The incorrect assumption going around here is that you are restricted to one precompiled header per solution. It's actually at most one per translation unit (source file), and I've succesfully used "one per project". Only the non-portable bits needed a PCH containing <windows.h> – Naples

Answer 2

When using precompiled headers, you should make sure your project compiles cleanly even without PCH present (so treat it as optimisation, not a replacement for includes in every TU). Aside from that, don't put absolutely everything in there (and more importantly, don't ever put headers from your own project — PCH should contain only those that don't change or change very rarely — system libraries, external dependencies), but rather try to keep most used/biggest things precompiled.

Alleyn

Answer 3

Personally, I would rather have slower compilation than no idea (visibility) how dependencies are. However, there are limits to everything.

As each project has its own pre-compiled header file, so I'd just put common-to-all-includes in there. Say if a project uses some boost headers those would fit well there as they will be used by the whole project and you're not changing them. Hence, put rarely/never changing headers in pre-compiled headers such as system or third party stuff.

For compilation speed, I'd rather rely on as much as possible to forward-declare things, split into smaller libraries and try to see if things can be organized in a way where volatile code is not affecting recompilation of much other code.

Mayst

Answer 4

Yor compiler might have a "show includes" flag. Turn it on, and look for deeply nested include hierarchies that are repeated. Consider including one of the most shallow include files to your header for each such deep trees.

Forrestforrester

Answer 5

Conditionally include the PCH's, then define something like "#define _PRE_COMPILE_" This way the original headers are still visible and the code is modular if you so need. An example of this would be to include

#ifdef _PRE_COMPILE_
#include "stdafx.h"
#elif
#include <iostream>
#include <cstring>
#endif

Include this at the beginning of every source file.

Eskisehir

Having an #ifdef before the #include "stdafx.h" doesn't work due to the way Microsoft's PCH implementation works. – Schaffner