Clarification of Debug/Release mode
-
Just looking for a clarification on Release/debug mode Isn't it true that I can generate Symbols .pdb file for a release Mode with the /Zi option so In debug it's Just using code generated by the pre-processor _DEBUG option such as #ifdef _DEBUG #define new debug_new #endif where a different heap storage allocator is used among other things Thanks
-
Just looking for a clarification on Release/debug mode Isn't it true that I can generate Symbols .pdb file for a release Mode with the /Zi option so In debug it's Just using code generated by the pre-processor _DEBUG option such as #ifdef _DEBUG #define new debug_new #endif where a different heap storage allocator is used among other things Thanks
The compiler and linker options are set initially to default values for the selected mode (debug or release). You can change the options according to your needs. Some tips:
- Use a new setting (e.g. by copying a default setting) if not changing basic options like the warning level
- You are not allowed to ship an application that is statically linked with debug versions of the run-time libraries or ship the dynamic debug versions with your applications.
The
NDEBUGsymbol is a standard C symbol that controls if the assert functions are active or not. You can remove it temporarily in release builds to test your code. The_DEBUGsymbol is a MS specific extension. It is set according to the selected/Mlinker option and controls if the release or debug versions of the run-time libraries should be used. Finally, the remaining main differences are that debug builds are compiled without optimisations and with (optional) additional checks like initialising memory and using guard bytes to detect out-of-bound accesses. -
Just looking for a clarification on Release/debug mode Isn't it true that I can generate Symbols .pdb file for a release Mode with the /Zi option so In debug it's Just using code generated by the pre-processor _DEBUG option such as #ifdef _DEBUG #define new debug_new #endif where a different heap storage allocator is used among other things Thanks
Commercially I don't ever use the DLL versions of the runtime libraries we live with the blowup in EXE code size. So for MFC I have the setting "Use Standard Windows Libraries" For C/C++ code generation I use "Multi-threaded (/MT)" in release mode and "Multi-threaded Debug (/MTd)" for debug The reason for it is sometime down the track your runtime DLL will fall foul of a new windows version. The compiler groups behind the runtime library are not as forward thinking as the proper O/S programmers at Microsoft. In general if you are using just the windows API the O/S programmers will patch those calls to still operate for old code although there is usually a speed penalty. I have code written originally for Windows 98 that still works on Windows 10, but I have had code written for runtime libraries that could survive between minor version changes of Windows. The school of hard knocks has taught me to avoid the runtime libraries at all cost because they are a liability.
In vino veritas
-
Commercially I don't ever use the DLL versions of the runtime libraries we live with the blowup in EXE code size. So for MFC I have the setting "Use Standard Windows Libraries" For C/C++ code generation I use "Multi-threaded (/MT)" in release mode and "Multi-threaded Debug (/MTd)" for debug The reason for it is sometime down the track your runtime DLL will fall foul of a new windows version. The compiler groups behind the runtime library are not as forward thinking as the proper O/S programmers at Microsoft. In general if you are using just the windows API the O/S programmers will patch those calls to still operate for old code although there is usually a speed penalty. I have code written originally for Windows 98 that still works on Windows 10, but I have had code written for runtime libraries that could survive between minor version changes of Windows. The school of hard knocks has taught me to avoid the runtime libraries at all cost because they are a liability.
In vino veritas
-
Leon when you say run time you referring to i.e. itoa, sprintf, strtol ? I guess for those you can write your own code
Yes, those are the functions but he is referring specifically to dynamic linking the RTLs. He prefers static linking the RTLs and for good reason. Your code will look the same either way. There are just a few compile and link options to deal with to change between them.
-
Leon when you say run time you referring to i.e. itoa, sprintf, strtol ? I guess for those you can write your own code
No the VC and MFC runtime libraries. Pull up control panel and go to the installed apps and features and roll to to Microsoft Visual C++. You will have a pile of things labelled as Visual Studio VC++ xxxx redistributable. Those are the same junk you have to package up with you EXE file when you go to place it on a new machine. All they are doing is trying to reduce the footprint of the EXE file itself by sitting it on a runtime library. It's the same as what Visual Basic does with it's runtime libraries and if I wanted to use Visual Basic I would write in Visual Basic not C++. Those redistributable libraries quite often develop bugs with new versions of Windows you notice you have to install them for every windows version you have a program written for. On my machine I have so many versions ... 2005, 2 x 2008, 2010, 2 x 2012, 2013, 2015, 2017 Using the settings I gave you the you create statically linked executable it flattens the EXE to only use the physical standard windows API in static linking. It means the EXE does not need anything else you can install it on a new Windows machine that has never seen a VC++ xxxx redistributable. The cost is it can be slower to compile because what looks like a minor change may setup big changes to what it does on code to the windows API and the EXE size will be some percentage bigger. As a guide my largest CAD program I make which is close to a million lines makes an EXE just over 3MBytes so it really isn't that dramatic. There used to be a problem with console apps where they would call out to the library but even that changed since Windows 7. The trick is you don't actually build a console app, you build a windows app and then call AllocConsole. The thing you end up with on screen looks and behaves like a console APP, but underneath they are very different. You will note the only attachment of the virtual console is kernel32.dll via kernel32.lib :-) AllocConsole function - Windows Console | Microsoft Docs[^] To make life interesting on Windows 10 they also allow users to bring up the old legacy console with an executable. Windows 10 Command Prompt: New Console vs. Legacy Console[
-
No the VC and MFC runtime libraries. Pull up control panel and go to the installed apps and features and roll to to Microsoft Visual C++. You will have a pile of things labelled as Visual Studio VC++ xxxx redistributable. Those are the same junk you have to package up with you EXE file when you go to place it on a new machine. All they are doing is trying to reduce the footprint of the EXE file itself by sitting it on a runtime library. It's the same as what Visual Basic does with it's runtime libraries and if I wanted to use Visual Basic I would write in Visual Basic not C++. Those redistributable libraries quite often develop bugs with new versions of Windows you notice you have to install them for every windows version you have a program written for. On my machine I have so many versions ... 2005, 2 x 2008, 2010, 2 x 2012, 2013, 2015, 2017 Using the settings I gave you the you create statically linked executable it flattens the EXE to only use the physical standard windows API in static linking. It means the EXE does not need anything else you can install it on a new Windows machine that has never seen a VC++ xxxx redistributable. The cost is it can be slower to compile because what looks like a minor change may setup big changes to what it does on code to the windows API and the EXE size will be some percentage bigger. As a guide my largest CAD program I make which is close to a million lines makes an EXE just over 3MBytes so it really isn't that dramatic. There used to be a problem with console apps where they would call out to the library but even that changed since Windows 7. The trick is you don't actually build a console app, you build a windows app and then call AllocConsole. The thing you end up with on screen looks and behaves like a console APP, but underneath they are very different. You will note the only attachment of the virtual console is kernel32.dll via kernel32.lib :-) AllocConsole function - Windows Console | Microsoft Docs[^] To make life interesting on Windows 10 they also allow users to bring up the old legacy console with an executable. Windows 10 Command Prompt: New Console vs. Legacy Console[
Leon thanks I understand what you are saying I just wanted to know what functions make up the run time libraries as far as MFC is concerned is it any way connected to the SDK version you are running Seems like sdk's have .lib file does MFC use that to resolve a call
-
Leon thanks I understand what you are saying I just wanted to know what functions make up the run time libraries as far as MFC is concerned is it any way connected to the SDK version you are running Seems like sdk's have .lib file does MFC use that to resolve a call
This is one of those things with frameworks is trying to understand what settings and what dependencies are built in the .lib or .dll file you end up with. You can't answer it easily without going on a fishing expedition. Again I don't use MFC enough to answer this definitively but I will give you want I expect to happen and these days you have the source code to MFC so you can rebuild it any way you want. So lets start the fishing. If it works like everything else on VS the header file will redirect it to the lib directory for MFC, for VS 2017 that will be C:\Program Files\Microsoft Visual Studio 14.0\VC\atlmfc\lib on the 32 bit Windows C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\lib on 64 bit Windows So I go there and I find lots of lib files which I expected. Now if I go up one directory and down to the include directory (I will assume 32 bit windows) C:\Program Files\Microsoft Visual Studio 14.0\VC\atlmfc\include Then pull up the main MFC header file afx.h you will see this, which is how they control which library gets used.
#ifndef _AFXDLL
#ifdef _AFX_NO_MFC_CONTROLS_IN_DIALOGS
#ifdef _DEBUG
#pragma comment(lib, "afxnmcdd.lib")
#else
#pragma comment(lib, "afxnmcd.lib")
#endif
#pragma comment(linker, "/include:__afxNoMFCControlSupportInDialogs")
#pragma comment(linker, "/include:__afxNoMFCControlContainerInDialogs")
#endif
#ifndef _UNICODE
#ifdef _DEBUG
#pragma comment(lib, "nafxcwd.lib")
#else
#pragma comment(lib, "nafxcw.lib")
#endif
#else
#ifdef _DEBUG
#pragma comment(lib, "uafxcwd.lib")
#else
#pragma comment(lib, "uafxcw.lib")
#endif
#endif
#else
#ifndef _UNICODE
#ifdef _DEBUG
#pragma comment(lib, "mfc" _MFC_FILENAME_VER "d.lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER "d.lib")
#else
#pragma comment(lib, "mfc" _MFC_FILENAME_VER ".lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER ".lib")
#endif
#else
#ifdef _DEBUG
#pragma comment(lib, "mfc" _MFC_FILENAME_VER "ud.lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER "ud.lib")
#else
#pragma comment(lib, "mfc" _MFC_FILENAME_VER "u.lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER "u.lib")
#endif
#endif
#endif#ifdef _DLL
#if defined(_DEBUG)
#pragma comment(lib, "msvcrtd.lib")
#else
#pragma comment(lib, "msvcrt.lib")
#endif
#else
#if defined(_DEBUG)
#pragma comment(lib, "libcmtd.lib")
#else
#pragma comment(lib, "libcmt.lib")
#endif
#endifDoes that answer you