views:

10497

answers:

5

I see so much code including stdafx.h. Say, I do not want pre-compiled headers. And I will include all the required system headers myself manually. In that case is there any other good reason I should be aware of where I require stdafx.h?

+1  A: 

Even without pre-compiled headers stdafx.h could be handy as it groups header includes and definitions common for all files.

You can of course choose to repeat all these definitions in every file. stdafx.h is not strictly necessary.

kgiannakakis
Bad practice - you ought to always explicitly list the headers you need so you can check module dependencies.
snemarch
stdafx usually includes platform specific definitions common for all files. It is a "dependency" of every file. You use it in order not to repeat the definitions in every file. This is a good practice, because you only do that in one place.
kgiannakakis
It is not a dependency of every file unless every file actually requires every header in stdafx. In practise this is rarely the case (IME). Using it in this way is lazy at best, bad practise at worst
Patrick
A common stdfax.h will include #pragma once directive, windows OS version definition and includes like windows.h or stdio.h. Why is it bad to group all these?. Also if you have a header of your own, that IS actually required by all files, why not put it there? Bad practice is to do otherwise.
kgiannakakis
#pragma once doesn't help you across module boundaries without enabling pch support (try inserting a #pragma message in windows.h). Not all files in a decent project will need windows.h/stdio.h/etc. For more reasons, check my answer...
snemarch
Then not include stdfax.h in the files that don't need all of its definitions. Do include though for the files that they actually need them; and in a decent project there are actually a few.
kgiannakakis
A: 

stdafx.h is just another header file. If you fell you don't need it feel free to not include it and remove it from the project.

However it's quite typical to have a file like stdafx.h exactly for precompiled headers to work and to not include all the stuff manually in each source file.

sharptooth
+4  A: 

If you don't want to use precompiled headers, then there is no point to using a standard include file - this will slow down the build for every file that includes it and cause them to include extra stuff that they do not need. Get rid of it and just include the headers they need.

1800 INFORMATION
+1  A: 

As others have mentioned: if you don't need precompiled headers, you don't really need stdafx.h . And using it just to group common includes is pretty bad practice, actually.

In fact, even when using precompiled headers, it's good practice to include the headers your process actually needs after stdafx.h (or precompiled.h or whatever you want to call it) - along with #ifdef magic in your precompiled header to turn off the usage of PCH.

Why? In order to check your module dependencies. Being able to disable your PCH lets you catch whether you're including necessary modules or not, and you can then write a tool to check your module interdependencies by parsing your .cpp and .h files (excluding the PCH header, of course).

snemarch
+2  A: 

You can use pre-compiled headers (which are a good thing) without using stdafx.h (I abominate it too). I've only got access to VC++ 6.0 but in that go to Project Settings|C/C++|Precompiled Headers and select "automatic use of precompiled header" but leave the "compiled through" box empty.

anon