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

有一些缺点:

• 更大的exe大小(如果您发送多个exe)
• 使用其他依赖或假设动态链接的dll时出现问题(例如:第三方dll,不能作为静态库获得)
• 具有独立静态链接的DLL之间的不同C运行时(没有跨模块分配/解除分配)
• 没有共享组件的自动服务(没有能力让第三方模块供应商在不重新编译和更新应用程序的情况下更新其代码来解决问题)

我们为我们的Windows应用程序做静态链接,主要是因为它允许xcopy部署,这在安装或依赖sxs dll时是不可能的,因为过程和机制没有很好的文档记录或很容易地删除。如果您在安装目录中使用本地dll,它会起作用,但不受很好的支持。不通过远程系统上的MSI就无法轻松地进行远程安装,这是我们不使用动态链接的主要原因,但(正如您指出的)静态链接还有许多其他好处。每种方法都有利弊;希望这有助于列举它们。

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

坦率地说,我认为这些都是弊,而不是利。当第三方动态链接库被更新时,它的变化足以破坏您的软件。现在,硬盘空间不再像以前那样宝贵了,你的可执行文件增加了50万块?谁在乎?

• 100%确定软件使用的DLL版本是一件好事。
• 100%确定客户不会有依赖性头痛是一件好事。

在我看来,好处远远大于坏处。

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

不幸的是,有些库不能静态链接。我有一个最好的例子是OpenMP。如果利用Visual Studio的OpenMP支持,则必须确保安装了运行时(在本例中是vcomp.dll)。

如果你确实使用了动态链接库,那么你就不能在没有一些严肃体操的情况下来回传递一些项目。Std::想到了字符串。如果您的exe和dll是动态链接的,则在crt中进行分配。否则,您的程序可能会尝试在一端分配字符串,在另一端取消分配。坏事接踵而至…

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

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

不,前面没什么新的。就这样吧。

非常肯定。

分配是在“静态”堆上完成的。由于应该在同一堆上分配一个释放,这意味着如果您发送一个库,您应该注意客户机代码不能调用“your” p = new LibClass() 并使用删除该对象本身 delete p; .

我的结论是:要么屏蔽分配和释放客户端代码,要么动态链接CRT。

有些软件许可证(如LGPL)要求您要么使用DLL,要么将应用程序作为用户可以链接到一起的对象文件分发。如果您正在使用这样的库,您可能会希望将它用作一个dll。