大家一定见过这样的提示吗:
Detected memory leaks!
Dumping objects ->
{57} client block at 0x00BE2E88, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $00BE2E88, 64 bytes long
a CDynLinkLibrary object at $00BE2E88, 64 bytes long
{55} client block at 0x00BE2D38, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $00BE2D38, 64 bytes long
a CDynLinkLibrary object at $00BE2D38, 64 bytes long
{50} client block at 0x00BE4F10, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $00BE4F10, 64 bytes long
a CDynLinkLibrary object at $00BE4F10, 64 bytes long
{48} client block at 0x00BE4DC0, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $00BE4DC0, 64 bytes long
a CDynLinkLibrary object at $00BE4DC0, 64 bytes long
Object dump complete.
经过我2天时间的研究,终于发再其规律,我不确定我的结论对不对,至少目前看来是对的。找问题的时候,我走了许多弯路,也在网上找过许多资料,所以写了这篇文章,希望对还像我一样在摸索的人有点帮助。
上面的内存泄漏,VS6.0说有,但BoundsChecker说没有,我也不知道有没有,总之看着碍眼!
其实问题的根源就是在MBCS Debug版本下使用Unicode Debug版本的动态库造成的(在Unicode Debug版本下使用MBCS Debug版本的动态库有没有此问题,我不确定,因为没试过),解决办法就是,编译一个Unicode Debug版本的动态库给Unicode 版本的应用程序使用即可。动态库的代码我一个字没动过,上面的内存泄漏问题就解决了!
所以,我现在的动态库都提供4个版本,MBCS的Release和Debug版、UNICODE的Release和Debug版,然后在.h文件里写上:
#ifdef _UNICODE
#ifdef _DEBUG
#pragma comment(lib, "ST_CommCtrlUD.lib")
#else
#pragma comment(lib, "ST_CommCtrlU.lib")
#endif
#else
#ifdef _DEBUG
#pragma comment(lib, "ST_CommCtrlD.lib")
#else
#pragma comment(lib, "ST_CommCtrl.lib")
#endif
#endif
这样,二次开发者只要include头文件,其它不用做任何事,就搞定了,不管什么版本自动适应。当然,生成的lib和dll文件的名字要不同。
注:如果动态库用VS2003编写,则无论如何使用,均没有内存泄漏,VS2005没试过,不知道。