简单的图书馆问题 (C++)
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)
1. Are shared libraries and dynamic libraries the same exact thing?
windows just labels them as .dll, and linux labels them as .so?
2. If a shared libarary has a ton of functions that a program uses, when are those functions loaded into memory?
At the start of the program? when the particular function is actually called?
3. If I make a library like this:
#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
and my client program only calls one of those functions, will their be performance decrease because of all the other extra functions not used?
Not worried about compilation time.. just the actual running time
4. Is question 3's scenario different if I use a class:
#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. I'm use to making a lot of objects(.o files), and then linking them together to make my executable.
would it be better to turn all of my objects(which are usually classes) into a .so file AND THEN link them together?
I understand that the executable will rely on the .so file, unlike the first approach where the objects can just be deleted after compilation, but what is the recommendation on this?
6. I'm a bit in the dark about the difference between -fPIC and -fpic
I've heard that -fPIC will always work and -fpic is target-dependent.
What does target dependent mean? If the library is always going to be compiled and used on the same machine, am I safe to use -fpic?
some of these questions may be trivial, but I want to be certain
about the things I've read so far. I appreciate any and
all responses
*If relevant: using gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于第一个问题和第二个问题：
在Windows Xp中，线程有dll（动态链接库）作为组件。线程可以被认为是轻进程。进程只不过是执行中的程序。（运行时）。我猜dll和.so是相似的（可能存在变化，不确定）
外部库通常以两种形式提供：静态库
和共享库。静态库是“.a”文件。什么时候
程序链接到静态库，机器代码来自
程序使用的任何外部函数的目标文件都是从
库到最终的可执行文件中。
链接到共享库的可执行文件仅包含一小部分
它需要的函数表，而不是完整的机器代码
来自外部函数的目标文件。可执行文件之前
开始运行，外部函数的机器代码被复制到
操作系统从磁盘上的共享库文件中获取内存 - a
过程称为动态链接。动态链接使可执行文件更小并节省磁盘空间，因为库的一份副本可以在多个程序之间共享。
对于第三个问题：由于在共享库中仅加载函数表而不是代码的实际助记符，因此我们保存的数据与静态库不同，静态库在编译时加载助记符。这可以从上面的解释中推断出来。
对于第五个问题：我认为只有当你知道你很少使用这些函数时，才将它们设置为“.so”会更好。如果你要经常使用这些函数，那么将它们设置为“.so”包含 lib 的静态函数。在运行时获取它们会增加响应时间。
For 1st and 2nd question :
In Windows Xp threads have dll's(Dynamic link libraries) as component.As a thread can be considered as light process. A process is nothing but program in Execution.(run time).I guess dll and .so are similar (there might exist variation ,not sure)
External libraries are usually provided in two forms: static libraries
and shared libraries. Static libraries are the ‘.a’ files . When
a program is linked against a static library, the machine code from the
object files for any external functions used by the program is copied from
the library into the final executable.
An executable file linked against a shared library contains only a small
table of the functions it requires, instead of the complete machine code
from the object files for the external functions. Before the executable file
starts running, the machine code for the external functions is copied into
memory from the shared library file on disk by the operating system—a
process referred to as dynamic linking.Dynamic linking makes executable files smaller and saves disk space,because one copy of a library can be shared between multiple programs.
For 3rd question : since in shared library only table of functions gets loaded not the actual mnemonics of code so we are saving data unlike static library where mnemonics are loaded at compile time.Which can be inferred from above explanation.
For 5th question : I think it will be better to make them as '.so' only when you know that you are going to those functions rarely.if you are going to use those function often then make those functions containing lib as static.As fetching them at run time increases responsive time .
在 Win 下，
dll's是动态链接库，这意味着它们在运行时单独加载到内存中，这与嵌入到您的程序中的静态链接库（lib's）不同。在Win下，在程序启动之前。如果找不到它需要的dll，它将报告错误消息并退出。除非您通过
LoadLibrary和GetProcAddress动态尝试调用函数而不是实际链接到库。没有。加载库时，这些函数在内存中具有众所周知的位置。无论有多少个函数，每个函数调用都只有一个
jmp或call指令。也没有。这些函数很可能会被表示为将
this作为额外参数的非成员函数。主要原因是可重用性。如果您有一个功能独立的模块，其中包含多个目标文件，您不妨将它们分组在一起。这样您就可以更轻松地重用它，因为您只需链接到一个库而不是多个目标文件。
？？？
Under Win,
dll'sare dynamic linked libraries, meaning they get loaded separately in memory at run-time, unlike static linked libraries (lib's) that are embedded in your module during compilation.Under Win, before the program starts. If it can't find a dll it needs, it will report an error message and exit. That's unless you dynamically try to call functions and not actually link against the library, via
LoadLibraryandGetProcAddress.No. The functions have a well-known place in memory when the library is loaded. There is only one
jmporcallinstruction per function call regardless of how many functions there are.Also no. Most probably those functions will be represented as non-member functions that take
thisas an extra parameter.The main reason would be re-usability. If you have a functionally independent module that contains multiple object files, you might as well group them together. That way you can re-use it more easily because you'd be linking to just one library instead of multiple object files.
???