在90年代,当我刚开始使用MFC时,我经常动态链接我的应用程序并发布相关的MFC DLL。这给我带来了一些问题(DLL地狱!),所以我转而采用静态链接-不仅是对于MFC,还包括CRT和ATL。除了EXE文件更大之外,静态链接从未给我带来任何问题-因此,其他人是否遇到过任何缺点呢?重新考虑动态链接是否有充分的理由?就FWIW而言,我的应用程序现在主要是STL / Boost。
我听到的大多数关于这个问题的答案都涉及共享你的dll文件给其他程序,或者让那些dll文件在无需修补你的软件的情况下进行更新。
坦白地说,我认为这些是缺点而不是优点。当第三方dll被更新时,它可能会发生足够的变化导致你的软件出现故障。而现在,硬盘空间不像过去那样珍贵,你的可执行文件多500k?谁在意呢?
在我看来,优点远远超过缺点。
存在一些缺点:
我们在Windows应用程序中使用静态链接,主要是因为它允许xcopy部署,而依靠SxS DLL以一种有效的方式进行安装或依赖是不可能的,因为该过程和机制没有得到很好的记录或易于远程操作。如果在安装目录中使用本地DLL,则它会有点起作用,但受支持性不强。我们不使用动态链接的主要原因是难以轻松地进行远程安装,而不必通过远程系统上的MSI进行,但是(正如您所指出的),使用静态链接还有许多其他好处。每种方法都有优缺点。希望这有助于列举它们。
DLL的一个优点是,如果多个进程加载同一个DLL,它们之间可以共享代码。这可以节省内存,并缩短应用程序加载已被另一个程序使用的DLL的时间。
有一些软件许可证,比如LGPL,要求你使用DLL或者分发应用程序作为用户可以链接在一起的目标文件。如果你正在使用这样的库,你可能想要将其作为DLL使用。
没有,关于那方面没有新的进展。保持现状就好。
当然。
分配是在“静态”堆上完成的。由于分配和释放应该在同一堆上完成,这意味着如果您发布一个库,您应该注意客户端代码不能调用“您”的p = new LibClass()
并使用delete p;
删除该对象。
我的结论:要么保护客户端代码免受分配和释放的影响,要么动态链接CRT。