c++ - 动态链接与静态链接效率

标签 c++ dll static-libraries

我与另一位开发人员发生争执,我想在这里解决动态链接与静态链接的问题。

理论上:

假设您有一个包含 100 个函数的库,每个函数中都有大量代码:

int A()
int B()
int C()
..
..and so on...

并且您的应用程序只调用或依赖其中之一。

您可以使用两种方法。

  1. 将库构建为动态链接库
  2. 将库构建为静态链接库

我的同事声称将静态库链接到我们的应用程序,编译器/链接器将 不会添加 99 个未使用函数的代码到我们的可执行文件中。我声称它会。我声称在这种情况下,唯一的优势是拥有单个可执行文件,而不必与我们的应用程序一起分发库,但如果我们使用动态链接库方法,它不会有显着的大小差异。

谁是对的?

最佳答案

这可能取决于代码的组织方式以及您使用的编译器标志的组合。

遵循经典的、简单的事物模型,链接器将链接到库中满足符号引用所需的任何目标文件,因此如果您的 A()、B() 和 C() 分别在不同的文件中定义目标文件,只有包含您实际使用的符号的目标文件才会链接到程序中(除非它又依赖于一个或多个其他文件,在这种情况下,链接器会找到目标文件来满足这些引用同样,递归地,直到它要么满足所有条件,要么找到一个它不能满足的条件(此时您会收到标准的“Unresolved external XXX”错误消息)。

最近,大多数编译器可以将函数“打包”到单独的“模块”中,而无需将它们放入单独的源文件中以创建单独的目标文件。细节各不相同,但可以减少(或消除)使每个源文件尽可能小的必要性,只是为了将最终可执行文件中的内容保持在最低限度。

所以,底线是:至少在大多数情况下,他是对的,而你是错的。

关于c++ - 动态链接与静态链接效率,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14286588/

相关文章:

c++ - 如何在Windows下使用cmake在qt GUI应用程序中显示控制台

c++ - 带有 Javascript 桥的 Ember.js QT

c++ - 主框架中的 MFC GUI 和其他也需要 GUI 的 DLL

c# - 结合 C# 和 C 的优点/缺点

c# - 如何将函数指针从 C# 传递到 C++ Dll?

objective-c - 构建一个使用 cocoapods 的可分发静态库

c++ - 工作 "within"结构 C/C++

c++ - 获取错误 : invalid conversion from 'int' to 'std::ios_base::openmode'

ios - 将 C 库更改为 IOS 库时出现错误

具有相同第三方库的 iOS 静态库导致重复符号错误