静态或动态链接CRT，MFC，ATL等

Question

早在90年代，当我第一次开始使用MFC时，我曾经动态链接我的应用程序并发送了相关的MFC DLL。这引起了我一些问题（DLL地狱！）而我改为静态链接 - 不仅仅是为了MFC，而是为了CRT和ATL。除了更大的EXE文件之外，静态链接从来没有给我带来任何问题 - 那么其他人是否有任何缺点？有没有充分的理由重新访问动态链接？我的应用程序现在主要是STL / Boost FWIW。

Answer 1

我听到的大多数答案都涉及与其他程序共享您的dll，或者在不需要修补软件的情况下更新这些dll。

坦率地说，我认为那些是缺点，而不是上升空间。当第三方DLL更新时，它可能会发生变化，足以破坏您的软件。而现在，硬盘空间并不像以前那么珍贵，可执行文件额外增加500k？谁在乎？

• 100％确定您的软件正在使用的dll版本是一件好事。
• 100％确定客户不会有依赖性头痛是一件好事。

上行远远超过我认为的缺点

Answer 2

有一些缺点：

• 较大的exe大小（特别是如果你发送多个exe）
• 使用依赖或假设动态链接的其他DLL的问题（例如：作为静态库无法获得的第三方DLL）
• 具有独立静态链接的DLL之间的不同c运行时间（没有跨模块分配/解除分配）
• 无需自动维护共享组件（无法让第三方模块供应商更新其代码以修复问题而无需重新编译和更新您的应用程序）

我们为我们的Windows应用程序进行静态链接，主要是因为它允许xcopy部署，这是以无法正常工作的方式安装或依赖SxS DLL所不可能的，因为流程和机制没有很好地记录或很容易远程处理。如果您在安装目录中使用本地DLL，它将有点工作，但它不受支持。无法通过远程系统上的MSI轻松进行远程安装是我们不使用动态链接的主要原因，但（正如您所指出的）静态链接还有许多其他好处。各有利弊;希望这有助于列举它们。

Answer 3

只要您将使用限制在某些库中并且不使用任何dll，那么您应该是好的。

不幸的是，有些库无法静态链接。我最好的例子是OpenMP。如果您利用Visual Studio的OpenMP支持，则必须确保安装了运行时（在本例中为vcomp.dll）。

如果你确实使用了dll，那么你就不能在没有严肃体操的情况下来回传递一些物品。想到std :: strings。如果您的exe和dll是动态链接的，那么分配将在CRT中进行。否则，您的程序可能会尝试在一侧分配字符串并在另一侧释放它。随之而来的是糟糕的事情......

那就是说，我仍然静态链接我的exe和dll。它确实减少了安装中的许多变化，我认为这非常值得一些限制。

Answer 4

使用dll的一个很好的特性是，如果多个进程加载相同的dll，则可以在它们之间共享其代码。这可以节省内存并缩短加载已经被其他程序使用的dll的应用程序的加载时间。

Answer 5

不，在这方面没什么新鲜事。保持这种状态。

Answer 6

绝对是。

分配在'静态'堆上完成。由于分配应在同一堆上进行解除分配，这意味着如果您运送库，则应注意客户端代码不能调用“您的”p = new LibClass()并使用delete p;删除该对象本身

我的结论：屏蔽分配和从客户端代码中释放，或动态链接CRT。

Answer 7

有些软件许可证（例如LGPL）要求您使用DLL或将应用程序分发为用户可以链接在一起的目标文件。如果您使用的是此类库，则可能需要将其用作DLL。