A problem occurred while the program was running, the Release,win64 bit mode was selected, and the macro definition Ndebug was seen, but the program still entered the upper part
The solution is to modify multi-threaded debugging (/MTD) inside the runtime of the property->c/c++-> code generator, as a multithreaded DLL (/MD).
After modification:
Compile a bit
Explain the reason from http://blog.csdn.net/u013829933/article/details/50321355, thank you ~ ~
Here is a summary of their differences, the back of the ' d ' is the Debug version, no ' d ' is the release version.
First of all,/MT.
/MT is "multithread, static version" means a multi-threaded static release, after defining it, the compiler placed LIBCMT.lib into the obj file, so that the linker uses LIBCMT.LIB to handle external symbols.
/MD is "Multithread-and dll-specific version", meaning the multi-threaded DLL versions, after defining it, the compiler placed MSVCRT.lib into the obj file, the way it connects to the DLL is statically linked, Actually the library of work is MSVCR80.DLL.
That
Static run-time library: LIBCMT.lib
Dynamic run-Time library: MSVCRT.lib + MSVCR80. Dll
So, when you use CMake to generate a project file, if CMake is generated with/MT (view CMakeLists.txt of the project's original directory), the runtime library it calls is: LIBCMT.lib, if the runtime library of the generated project If you choose/MD, the Dynamic Runtime library will be called when the project is linked at compile time: MSVCRT.lib + MSVCR80. DLL, obviously, two times a redefined error occurs when the library is different from a function call in the same runtime library. If the project generates a library file, it must also be/MT when the other project calls the library.
===============================================
VC project properties → configuration properties →c/c++→ code generation → runtime libraries can be used in the following ways: Multithreading (/MT), multithreaded Debugging (/MTD), multithreaded DLLs (/MD), multithreaded debug DLLs (/MDD), single-threaded (/ML), Single-threaded debugging (/MLD).
Reusable Library Switch Library Macro (s) Defined
Single Threaded |
/ml |
LIBC |
(none) |
Static multithread |
/mt |
LIBCMT |
_mt |
Dynamic Link (DLL) |
/md |
MSVCRT |
_MT and _dll |
Debug Single Threaded |
/MLd |
Libcd |
_debug |
Debug Static multithread |
/MTd |
Libcmtd |
_DEBUG and _MT |
Debug Dynamic Link (DLL) |
/MDd |
Msvcrtd |
_DEBUG, _MT, and _dll |
Where the option with the end of lowercase "D" represents the debug version, there is no "D" for release version. Large projects must require that all components and third-party libraries are run-time libraries that are unified, or LNK2005 blowout will occur.
Single-threaded run-time library options/ML and/MLD were discarded after VS2003.
/MT and/MTd represent the static Lib version of the multithreaded CRT library. This option completely embeds the run-time library as a static lib at compile time. The executable file generated by this option runs without the need for runtime library DLLs to participate, resulting in a slight performance gain, but the resulting binary code becomes very bloated because it is chained to a large runtime library implementation. When an item is embedded in multiple projects as a static-link library, it may result in multiple memory management of the runtime library, resulting in a fatal "Invalid Address specified to Rtlvalidateheap" issue. Additionally, the/MT and/MTD options are no longer supported in managed C + + and CLI.
/MD and/MDd represent the dynamic DLL version of the multithreaded CRT library, which causes the application to use a specific version of the runtime library's multithreaded DLLs. Links will follow the traditional VC link DLL to the runtime Library MSVCRxx.DLL Import Library MSVCRT.lib link, at run time requires the corresponding version of the VC Runtime Library Redistributable Package (of course, these run-time library DLLs in the application directory is also possible). Because the/MD and/MDd methods do not link the runtime library to the inside of the executable file, the executable file size is reduced effectively. When multiple projects operate in MD mode, the same heap is used internally, memory management is simplified, and cross-module memory management issues are mitigated.
Conclusion:/MD and/MDD will be the trend,/ML and/MLD mode please give up in time,/MT and/MTD should not be used when not necessary.
VS runtime differences between/MD,/MDd, and/MT,/MTD