mfcm.cpp导致内存泄漏 [英] mfcm.cpp causing memory leaks

问题描述

我一直遇到内存泄漏问题，并且使用调试方法的问题源在第29行的mfcm.cpp中进行了说明.该代码通过以下步骤设置了mfcm80DLL动态链接库的负载:

新的CDynLinkLibrary(mfcm80DLL);

但是代码中似乎没有关联的FreeLibrary.

我正在使用该库将System命名空间用于我需要的各种数据.
当潜在的来源是mfc代码时，如何解决内存泄漏问题?

I have been getting a problem with a memory leak, and using the method of debugging the source of the problem was stated as in mfcm.cpp at line 29. The code sets up the load of the mfcm80DLL Dynamic Link Library via:

new CDynLinkLibrary(mfcm80DLL);

however there does not seem to be an associated FreeLibrary in the Code.

I am using this library to use the System namespace for various bits of data that I require.
How do I get round the memory leak problem, when the potential source is the mfc code?

推荐答案

^ ]的外观像是对问题的解释.显然，如果您使用与其他版本的MFC DLL链接的DLL且无害.

需要考虑的几件事...并非所有的内存泄漏都值得追踪.例如，编译器经常对动态内存使用斜杠和刻录方法-他们分配它，而从不费力地释放它. C ++中真正的问题不一定是内存泄漏，而是析构函数没有被调用.

无论您做什么，都不会在代码中编写新的T.无需立即将结果分配给某种智能指针.这样就永远不会泄漏内存，并且所有析构函数都将被调用.

This[^] looks like an explanation of the problem. Apparently if you use DLLs linked with different versions of the MFC DLL and is harmless.

A couple of things to consider... Not all memory leaks are worth tracking down. Compilers for example often use a slash and burn approach to dynamic memory - they allocate it and never bother releasing it. The real problem in C++ is not necessarily the memory leaking it''s that the destructor doesn''t get called.

And whatever you do, in your code never write new T; without immediately assigning the result to a smart pointer of some sort. Then you''ll never leak memory and all your destructors will be called.

这篇关于mfcm.cpp导致内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！