coldfall:

对应的，如果你使用DLL，由于DLL中会自行初始化一份CRT堆，因此它的内存申请与释放是在有别于在EXE的CRT堆中进行的（两个不同的CRT堆），如果你从DLL中申请一块内存出来使用，最后也必须交还给DLL模块内部去释放。否则会产生Heap Collision，在Debug模式下，你会收到一个系统位于malloc中的断言，并了解到发生了什么。
=============================
对这一段话持不同意见，DLL中使用malloc或者new申请的堆内存是由其加载的MSVCRT.dll或其他的C/C++运行库DLL来分配和管理的，因此如果整个虚拟空间中只有一份该DLL映射，对于堆的管理是不会有问题的。出现你上面提到的问题，多半是因为EXE和DLL使用了不同版本的MSVCRT.dll等运行库DLL，因此EXE运行时是由运行时库DLL1来管理堆，而DLL是由运行时库DLL2来管理堆，也就会发生了上面的问题，因为DLL1中的堆中并没有DLL2中分配的堆内存，各自有各自的CRT堆，各管各的。

非常感谢您的质疑。
针对该情况，我编写了一个测试程序进行验证，发现确实是我此前对这个问题产生了误解。

情景如下：
在Dll中导出一个函数
char* allocMem(int size)
{
return (char*) malloc(size);
}

并在EXE中直接free该函数返回的指针。

分两种情况：
1. 如果EXE与DLL使用的是同一个的msvcrt，不仅仅是版本，则不会出现问题。（/Md, /Mt）
2. 如果EXE与DLL使用的是不同的msvcrt，则会引发我所提到的堆内存错误。（此前我误解为每个Dll会有一个自己的堆，事实上应是每一个crt有一个自己的堆）

这里所说的“同一个”，特指两个2进制模块都链接的是动态crt。如果其中有一个使用的是静态CRT就不行。

究其原因，是由于CRT采用全局变量_crtheap维护了一个Heap的句柄，因此如果所有二进制模块都通过动态链接的方式使用同一个CRT，就不会引发问题。

然而，如果有某个模块链接了一份静态CRT，由于被静态链接到二进制文件中的全局变量会独立存在，因此会使得同一个进程存在使用了两个或更多的crt堆的情况。

semicircle21:

1. 我觉得 3.a里: 只提供一系列普通函数就很方便,就好像ws2_32.lib那样…你说的“只提供一系列普通函数以及一个实现类的指针”是啥意思?
2. 现在你只关注win32了? linux的lib/so一点都没涉及阿,其实linux动态库的东西也很有意思。

1.pImpl 惯用法，之前我也没搞太清楚 = = 这篇文章有些地方会再改改。
2.实际两者的动态链接本质上没什么大差别。

2. 现在你只关注win32了? linux的lib/so一点都没涉及阿,其实linux动态库的东西也很有意思。

牛逼