[ACCEPTED]-Visual C++ 'Force Includes' option-visual-c++

I would say the opposite to litb above if 14 you're using precompiled headers. If you 13 use "stdafx.h" as your precompiled header 12 and have code like this:

#include "afile.h"
#include "stdafx.h"

then you'll be spending 11 an age trying to figure out why "afile.h" isn't 10 being included. When using precompiled headers, all 9 the includes and #defines are ignored up 8 to the "stdafx.h". So, if you force include 7 the "stdafx.h" then the above will never 6 happen and you'll get a project that uses 5 the precompiled option efficiently.

As for 4 litb's comment about finding macros, good 3 IDE's usually have an option to jump to 2 the definition of a symbol, whether it be 1 a #define, function, class, etc.

I would discourage from /FI (MSDN says it's 8 called /FI . Not sure whether i looked at 7 the right page though), simply because people 6 or yourself reading the files don't notice 5 a header is magically included anyway.

You 4 can be sure this will cause much debugging 3 time for someone that wants to figure out 2 where specific macros come from, even though 1 there are no #include lines at the top of the file.

Force includes is also helpful for automatically 9 generated source files. Our system uses 8 a tool that generates many source files 7 but they don't include our pre-compiled 6 header file. With "force includes" compilation 5 of these files is now faster.

Optionally, it 4 would be possible to write a script to insert 3 the #include line in those files after generation 2 and before compilation. But why go to that 1 trouble?

I'd side with litb: don't do the forced 9 includes. Having the code be explicit makes 8 it easier to know what's going on for a 7 new user. It also makes it easier to know 6 what's going on if you ever need to port 5 the code to a new platform.

Note that if 4 the code uses templates, Visual Studio usually 3 can't track down the definitions correctly. Perhaps 2 2010 will be better, but even VS 2008 is 1 problematic on this front.

I wouldn't use it that often but it has 18 its uses. I have used it to add a header 17 that suppressed some warnings to all cpp 16 files so that I could turn on /W4 or /Wall 15 for the project and not have to edit all 14 of the cpp files to include the warning 13 suppression header first. Once eveything 12 was working I DID go back and edit all the 11 cpp files but for a proof of concept /FI 10 was useful.

Likewise you can use it to force 9 a precompiled header into cpp files in some 8 build configurations but not in all (in 7 case you want to have a build configuration 6 that DOESNT use precompiled headers and 5 that makes sure that each cpp only includes 4 exactly what it needs to). However using 3 #pragma hdrstop is, IMHO, a better way to 2 achieve this.

I've talked about all of this 1 on my blog here: http://www.lenholgate.com/blog/2004/07/fi-stlport-precompiled-headers-warning-level-4-and-pragma-hdrstop.html in a little more detail.

Save this function for when something weird 3 comes up - like if you want to include a 2 header in a generated source file. Even 1 then there are likely better ways.