Why does stdafx.h work the way it does?

Question

Hi all..

As usual, when my brain's messing with something I can't figure out myself, I come to you guys for help :)

This time I've been wondering why stdafx.h works the way it does? To my understanding it does 2 things:

• Includes standard headers which we might (?) use and which are rarely changed
• Work as a compiler-bookmark for when code is no longer precompiled.

Now, these 2 things seems like two very different tasks to me, and I wonder why they didn't do two seperate steps to take care of them? To me it seems reasonable to have a #pragma-command do the bookmarking stuff and to optionally have a header-file a long the lines of windows.h to do the including of often-used headers... Which brings me to my next point: Why are we forced to include often-used headers through stdafx.h? Personally, I'm not aware of any often used headers I use that I'm not already doing my own includes for - but maybe these headers are necessary for .dll generation?

Thx in advance

Answer 1

It will help reduce long compilations.

Answer 2

You are not forced to use "stdafx.h". You can check off the Use precompiled headers in project properties (or when creating the project) and you won't need stdafx.h anymore.

The compiler uses it as a clue to be able to precompile most used headers separately in a .pch file to reduce compilation time (don't have to compile it every time).

Answer 3

It keeps the compile time down, as the stuff in it are always compiled first (see details in quote below):

stdafx.h is a file that describes both standard system and project specific include files that are used frequently but hardly ever changed.

Compatible compilers will pre-compile this file to reduce overall compile times. Visual C++ will not compile anything before the #include "stdafx.h" in the source file, unless the compile option /Yu'stdafx.h' is unchecked (by default); it assumes all code in the source up to and including that line is already compiled.

Answer 4

stdafx.h is ONE way of having Visual studio do precompiled headers. It's a simple to use, easy to automatically generate, approach that works well for smaller apps but can cause problems for larger more complex apps where the fact that it encourages, effectively, the use of a single header file it can cause coupling across components that are otherwise independent. If used just for system headers it tends to be OK, but as a project grows in size and complexity it's tempting to throw other headers in there and then suddenly changing any header file results in the recompilation of everything in the project.

See here: http://stackoverflow.com/questions/290034/is-there-a-way-to-use-pre-compiled-headers-in-vc-without-requiring-stdafxh#293219 for details of an alternative approach.