Notes about the compiler flags which the MicroSoft C compiler assigns when the IDE is in release mode
compiler flags
Documentation about compiler flags for the Micorosoft C compiler.
A mirror copy of the documentation.
This is the typical compile line for the Microsoft IDE in release mode:
/O2 /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Yu"stdafx.h" /Fp"Release\hello.pch" /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt
/O2
/O2 maximize speed
/GL
/GL enable link-time code generation
Whole program Optimization is described here and mirrored here.
Note the following:
The format of files produced with /GL in the current version may not be readable by subsequent versions of Visual C++. You should not ship a .lib file comprised of .obj files that were produced with /GL unless you are willing to ship copies of the .lib file for all versions of Visual C++ you expect your users to use, now and in the future.
.obj files produced with /GL and precompiled header files should not be used to build a .lib file unless the .lib file will be linked on the same machine that produced the /GL .obj file. Information from the .obj file's precompiled header file will be needed at link time.
I take this to mean, that you shouldn't use /GL at all. I suspect this is why I have to recompile all of Bill's code when he ships it to me.
/FD
/FD - I am not sure I understand this option. I think this is a use of the /F "set stack size" option, and that D is the stack size.
/EHsc
/EHsc = /EHs + /EHc = Use exceptions, but not structured exceptions, and warn if an extern "C" function uses an exception.
/EHs
/EHs - enable EH exceptions, but don't use SEH Structured Exception Handling
SEH is an abomination .
Here is a mirror.
/EHc
/EHc - extern "C" defaults to no throw. If an extern "C" function has a throw statement, then it will generate a benign warning.
/MD
/MD link with MSVCRT.LIB. I think this option is greatly superior to /MDd, because the Microsoft Debug version of functions like new, and malloc, call _memset to initialize all memory to 0. _memset is *slow*.
/Yu"stdafx.h"
/Yu"stdafx.h" - use a PCH, "Pre Compiled Header" file
/Fp"Debug\hello.pch"
/Fp"Debug\hello.pch" - names precompiled header file output
/Fo"Release\\"
/Fo"Release\\" - Put object files in Release directory
/Fd"Debug\vc80.pdb"
/Fd"Debug\vc80.pdb" - name of debugging information database. You can read about this (bad) idea here or at the mirror. This database makes it difficult to port compiled and linked code between machines because you always have to include the database, and because the database makes references to the directory tree, which is not clear. Does it reference the tree through relative paths, absolute paths or a combination of both? This database also enables one to do "edit" and "debug" at the same time. I suspect this capability slows the execution of the code.
Even worse, if you port a DLL, then you will have a separate database for the dll, and a separate database for the executing program. This has to confuse the heck out of the code level debugger.
/W3
/W3 - set to warning level 3 = lots of warnings.
Do you really need to be reminded that microsoft hates sprintf, fopen and all the ansi (non microsoft) functions?
/nologo
/nologo suppress copyright message
/c
/c compile only don't link
/Wp64
/Wp64 enable 64 bit porting warnings
/Zi
/Zi enable debugging information. I suspect this is results in faster code than /ZI.
/TP
/TP compile all files as C++ files, even C files
/errorReport:prompt
/errorReport:prompt prompt user before sending internal compiler errors to Msft