简单的图书馆问题(C ++)

时间:2011-12-07 23:05:04

标签: c++ gcc dynamic libraries shared

1。 共享库和动态库是否完全相同?
windows只是将它们标记为.dll,linux将它们标记为.so

2。如果共享库具有程序使用的大量函数,那么这些函数何时加载到内存中?
在计划开始时?什么时候实际调用特定的函数?

第3。如果我创建这样的库:

#ifndef SHARED_H
#define SHARED_H

#include <iostream>
#include <string>

namespace shared
{
  void Function1(void);
  void Function2(void);
  void Function3(void);
  void Function4(void);
  void Function5(void);
  void Function6(void);
  ...
  void Function99(void);
  void Function100(void);
  ...
}
//assume none of these functions call each other

#endif

,我的客户端程序只调用其中一个函数,由于未使用所有其他额外函数,它们的性能会降低吗?
不担心编译时间..只是实际运行时间

4。如果我使用课程,问题3的情景会有所不同:

#ifndef SHARED_H
#define SHARED_H

#include <iostream>
#include <string>

class Shared
{
  public:
  void Function1(void);
  void Function2(void);
  void Function3(void);
  void Function4(void);
  void Function5(void);
  void Function6(void);
  ...
  void Function99(void);
  void Function100(void);
  ...
  private:
  protected:
};
//assume none of these functions call each other

#endif

5. 我用来制作大量对象(.o文件),然后将它们链接在一起以制作我的可执行文件。 将所有对象(通常是类)转换为.so文件然后将它们链接在一起会更好吗?
我知道可执行文件将依赖于.so文件,不像第一种方法可以在编译后删除对象,但对此有何推荐?

6。关于-fPIC和-fpic 之间的区别,我有点不知所措 我听说-fPIC总是有效,-fpic是目标依赖的 目标依赖意味着什么?如果库总是要在同一台机器上编译和使用,我可以安全地使用-fpic吗?

  

其中一些问题可能微不足道,但我想确定   关于我到目前为止所阅读的内容。我很欣赏任何和   所有回复
  *如果相关:使用gcc版本4.6.1(Ubuntu / Linaro 4.6.1-9ubuntu3)

2 个答案:

答案 0 :(得分:6)

第一和第二个问题: 在Windows Xp中,线程有dll(动态链接库)作为组件。因为线程可以被视为轻量级进程。一个过程只不过是执行中的程序。(运行时)。我猜dll和.so是相似的(可能存在变化,不确定)

外部库通常以两种形式提供:静态库 和共享库。静态库是'.a'文件。什么时候 一个程序链接到一个静态库,机器代码来自 从中复制程序使用的任何外部函数的目标文件 将库放入最终的可执行文件中。

针对共享库链接的可执行文件仅包含一小部分 它需要的功能表,而不是完整的机器代码 来自外部函数的目标文件。在可执行文件之前 开始运行时,外部函数的机器代码被复制到 来自操作系统-a的磁盘上的共享库文件的内存 流程称为动态链接。动态链接使可执行文件更小并节省磁盘空间,因为可以在多个程序之间共享库的一个副本。

对于第三个问题:因为在共享库中只有函数表被加载而不是代码的实际助记符所以我们保存数据不像静态库,其中助记符是在编译时加载的。这可以推断出来从上面的解释。

对于第5个问题:我认为只有当你知道你很少去那些功能时才会把它们变成'.so'。如果你打算经常使用这些功能然后将包含lib的那些函数设置为static。在运行时获取它们会增加响应时间。

答案 1 :(得分:2)

  1. 在Win下,dll's是动态链接库,这意味着它们在运行时单独加载到内存中,而不像编译期间嵌入模块中的静态链接库(lib's

  2. 在Win下,程序开始之前。如果找不到它需要的dll,它将报告错误消息并退出。除非您通过LoadLibraryGetProcAddress动态尝试调用函数而不是实际链接到库,否则不会这样做。

  3. 没有。加载库时,这些函数在内存中有一个众所周知的位置。无论函数有多少,每个函数调用只有一个jmpcall指令。

  4. 也没有。很可能这些函数将表示为非成员函数,将this作为额外参数。

  5. 主要原因是可重复使用。如果您有一个包含多个目标文件的功能独立模块,您也可以将它们组合在一起。这样您就可以更轻松地重复使用它,因为您只链接到一个库而不是多个目标文件。

  6. ???