![](/img/trans.png)
[英]Difference between shared objects (.so), static libraries (.a), and DLL's (.so)?
[英]Difference between static and shared libraries?
静态库和共享库有什么区别?
我使用 Eclipse 并且有几种项目类型,包括静态库和共享库? 一个比另一个有优势吗?
共享库是 .so(或在 Windows .dll 中,或在 OS X .dylib 中)文件。 与库相关的所有代码都在此文件中,并且在运行时使用它的程序会引用它。 使用共享库的程序只引用它在共享库中使用的代码。
静态库是 .a(或在 Windows 中的 .lib)文件。 与库相关的所有代码都在这个文件中,并且在编译时直接链接到程序中。 使用静态库的程序从静态库中获取它使用的代码的副本,并使其成为程序的一部分。 [Windows 也有用于引用 .dll 文件的 .lib 文件,但它们的作用与第一个相同]。
每种方法都有优点和缺点:
共享库减少了使用该库的每个程序中重复的代码量,从而使二进制文件保持较小。 它还允许您用功能等效的共享对象替换共享对象,但可能会增加性能优势,而无需重新编译使用它的程序。 但是,共享库会产生少量额外的函数执行成本以及运行时加载成本,因为库中的所有符号都需要连接到它们使用的东西。 此外,共享库可以在运行时加载到应用程序中,这是实现二进制插件系统的通用机制。
静态库会增加二进制文件的整体大小,但这意味着您无需携带正在使用的库的副本。 由于代码是在编译时连接的,因此没有任何额外的运行时加载成本。 代码就在那里。
就个人而言,我更喜欢共享库,但在需要确保二进制文件没有许多可能难以满足的外部依赖项时使用静态库,例如特定版本的 C++ 标准库或特定版本的 Boost C++ 库。
静态图书馆就像书店,共享图书馆就像……图书馆。 对于前者,您可以将自己的书/功能副本带回家; 对于后者,您和其他所有人都去图书馆使用相同的书/功能。 因此,任何想要使用(共享)库的人都需要知道它在哪里,因为您必须“去获取”这本书/函数。 使用静态库,书籍/功能是你的,你把它保存在你的家/程序中,一旦你有了它,你就不会关心在哪里或何时得到它。
简化:
对于静态库,链接器从库中提取代码,并在您编译/构建应用程序时用于构建最终的可执行文件。 最终的可执行文件在运行时不依赖于库
对于共享库,编译器/链接器会在构建应用程序时检查您链接的名称是否存在于库中,但不会将它们的代码移动到应用程序中。 在运行时,共享库必须可用。
C 编程语言本身没有静态库或共享库的概念——它们完全是一个实现特性。
就个人而言,我更喜欢使用静态库,因为它使软件分发更简单。 然而,这是关于过去流过多少(比喻性的)血的观点。
静态库作为应用程序的一部分进行编译,而共享库则不是。 当您分发依赖于共享库的应用程序时,库,例如。 需要安装 MS Windows 上的 dll。
静态库的优点是运行应用程序的用户不需要依赖项——例如,他们不必升级他们的 DLL。 缺点是您的应用程序体积较大,因为您将它与它需要的所有库一起发送。
除了导致较小的应用程序,共享库还为用户提供了使用他们自己的库的能力,也许是更好的库版本,而不是依赖于应用程序的一部分
共享库最显着的优势在于,无论有多少进程正在使用该库,内存中都只加载了一份代码副本。 对于静态库,每个进程都有自己的代码副本。 这会导致显着的内存浪费。
OTOH,静态库的一个优点是一切都捆绑到您的应用程序中。 因此,您不必担心客户端将在其系统上提供正确的库(和版本)。
除了所有其他答案之外,还没有提到的一件事是解耦:
让我谈谈我一直在处理的真实世界生产代码:
一个非常大的软件,由超过 300 个项目(使用 Visual Studio)组成,主要构建为静态库,最后全部链接到一个巨大的可执行文件中,最终会遇到以下问题:
- 链接时间非常长。 您最终可能需要超过 15 分钟的链接,比如 10 秒的编译时间 - 有些工具面临如此大的可执行文件,例如必须检测代码的内存检查工具。 您可能会陷入被视为傻瓜的极限。
更大的问题是你的软件的解耦:在这个真实世界的例子中,每个项目的头文件都可以从任何其他项目中访问。 因此,一名开发人员非常容易添加依赖项; 它只是包含标题,因为最后的链接将始终可以找到符号。 它以可怕的循环依赖和完全混乱而告终。
使用共享库,这是一些额外的工作,因为开发人员必须编辑项目构建系统以添加依赖库。 我观察到共享库代码倾向于提供更清晰的代码 API。
-------------------------------------------------------------------------
| +- | Shared(dynamic) | Static Library (Linkages) |
-------------------------------------------------------------------------
|Pros: | less memory use | an executable, using own libraries|
| | | ,coming with the program, |
| | | doesn't need to worry about its |
| | | compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of | bigger memory uses |
| | libraries may be altered | |
| | subject to OS and its | |
| | version, which may affect| |
| | the compilebility and | |
| | runnability of the code | |
-------------------------------------------------------------------------
+---------------+---------------------------+------------------------------+
| properties | Static library | Shared library |
+===============+===========================+==============================+
| Linking time | It happens as the | Shared libraries |
| | last step of the | are added during |
| | compilation process. | linking process |
| | After the program | when executable |
| | is placed | file and libraries |
| | in the memory | are added to the memory. |
+---------------+---------------------------+------------------------------+
| Means | Performed by linkers | Performed by operating System|
+---------------+---------------------------+------------------------------+
| Size | Static libraries are | Dynamic libraries are |
| | much bigger in size, | much smaller, because |
| | because external | there is only one copy |
| | programs are built | of dynamic library |
| | in the executable file. | that is kept in memory. |
+---------------+---------------------------+------------------------------+
| External file | Executable file will | In shared libraries, |
| changes | have to be recompiled | no need to recompile |
| | if any changes were | the executable. |
| | applied to external files.| |
+---------------+---------------------------+------------------------------+
| Time | Takes longer to execute | It is faster |
| | because loading into the | because shared |
| | memory happens every time | library code is |
| | while executing. | already in the memory. |
+---------------+---------------------------+------------------------------+
| Compatibility | Never has a compatibility | Programs are dependent |
| | issue,since all code is | on having a compatible |
| | in one executable module. | library.Dependent program |
| | | will not work if library |
| | | gets removed from the system |
+---------------+---------------------------+------------------------------+
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.