   VS Compiler options (C++)
  Im wondering about the code generation commands such as/MT/MTd/MD/MDdAm i right in thinking that these are for the built in librarys for C++? This is what confuses me, i thought that they were pretty much all headers, im thinking the STL here btw. Could someone tell me what other librarys are being affected here? Is this the visual studio C++ runtimes? Which i thought setting "Common language Runtime support" to "Common Language Runtime Support (/clr)" caused the VS C++ runtimes to be statically linked.Do these settings have any effect on the code i have included in my project?My understanding of static linking is that it includes all the data in the .exe, where as dynamic links to it with the .dll. But reading MSDN for the /MD flag.Quote:/MD - Defines _MT and _DLL so that both multithread- and DLL-specific versions of the run-time routines are selected from the standard .h files. This option also causes the compiler to place the library name MSVCRT.lib into the .obj file.Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR71.DLL, which must be available at run time to applications linked with MSVCRT.lib.I thought MD was for dynamic linking, why does it mention static linking?Which flags should be generally set and why?    
  These define which MSVC's run-time C and C++ library gets linked.Dynamic - dllStatic - statically linkedThreaded/multi-threaded - hopefully self-explanatoryQuote:i thought that they were pretty much all headersStandard library is platform-agnostic, but its implementation isn't. fopen() and fstream() need an OS-specific call to actually open the file.This is what is in those libraries.It is however possible by design, to write valid C++ WinAPI applications without linking any of those. This requires either using C run-time library, or implementing the basic functions (memcpy, memset, perhaps malloc/new) yourself.Quote:Do these settings have any effect on the code i have included in my project?They determine how the resulting executable or dll is linked, and what is required to run/use it.Static linking means that user does not need MVC redistributables.   ;  The /clr switch changes the language from C++ to C++/CLI, the managed version of C++. If you want normal C++, leave this switch off.The C runtime and the C++ runtime libraries are what contains the implementation of the non-template portions of the C and C++ standard libraries. The C runtime contains things like the definitions for printf(), rand(), memcpy() and so on. The C++ runtime contains things like the definitions for std::exception, std::terminate(), std::set_new_handler() and so on.The C and C++ runtimes come in four versions: a debug DLL, a debug static library, a release DLL and a release static library. These correspond to the four switches /MDd, /MTd, /MD and /MDd. Generally, you'll want to use /MDd or /MTd for in debug mode and /MD or /MT in release mode.In recent versions of MSVC, using the DLL version of the runtimes will create a dependency in your application for the runtime redistributable. You'll generally need to install the redistributable if you want your application to run on a computer that doesn't have MSVC installed. Using the static library version will not have that dependency, but may conflict with other libraries that you may use.   ;  oh ok. So when users run an app made with vs 2008 and they get that runtime library missing error, which can be resolved by downloading the vs 2008 runtimes from MSDNMicrosoft Visual C++ 2008 Redistributable Package (x86)http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=enIt can also be resolved by using MT instead of MD?   ;  It might be resolved by using /MT. If the application uses any libraries that also depend on the DLL version of the runtimes, you'll still need it for those libraries.   ;  Yes it can, but it has other side effects as well: You can't transfer ownership of heap-allocated memory between dlls (or an executable and a dll). The memory needs to be released in the dll it was allocated which doesn't work when you want to pass a std container by value for example.   