我经常避免使用大型头文件只使用一个函数，认为这样做会导致性能下降。所以，我只是在代码中实现该函数，它将按预期工作。
最后，我意识到这几乎破坏了图书馆的整个概念，尽管耗费时间。
考虑到这一点，C编译器倾向于将程序动态链接到libc共享库（您可以通过使用命令看看哪些库是动态链接的：ldd＆lt; program_path＆gt;）。那么，这并不意味着链接到整个库的性能足够，我不需要关心单个文件包含？
可执行文件是否包含整个库函数，或仅包含已使用的函数？
我想知道是否存在任何C / C ++差异。
答案 0 :(得分：3)
＆＃34;所以，这并不意味着链接到整个库的性能足够，我不需要关心单个文件包含？＆＃34; < / p>
我不完全明白，在这里您可以看到性能问题。包含头文件由c预处理器优化，链接是一个不同的阶段，并由链接器优化 虽然通常有很好的理由，只是使用函数或类的前向声明，而不是包含整个头。但这与性能无关。
＆＃34;可执行文件是否包含整个库函数，或仅包含已使用的函数？＆＃34;
如果使用静态链接，链接器将只添加使用过的函数。
＆＃34;我想知道是否存在任何C / C ++差异。＆＃34;
没有
答案 1 :(得分：2)
添加回答πάνταῥεῖ：
包含头文件在运行时没有任何成本。包含头文件将导致预处理器将头文件的内容转储到包含头的位置的程序中。 C头文件不包含任何导致编译器在包含它们时发出代码的内容。虽然标题可以这样做，但这被认为是糟糕的风格并且不赞成。
在使用ELF作为其二进制文件（Linux，BSD，Solaris，Unix，...）的系统上，除了具有static链接的函数之外的所有函数都通过PLT调用。这是一个表，每个可以调用的函数都有一小段代码。程序启动时，PLT只包含占位符。第一次调用函数时，链接器解析其地址并替换PLT中的代码，因此下一次调用函数不会通过链接器，实际上并不比没有通过PLT的调用慢得多。额外费用是一次跳转指令。
当程序启动时，链接器会将程序所依赖的所有库加载到进程的地址空间中。这并不意味着实际上将从硬盘中读取库;操作系统只读取实际需要的硬盘部件。
一旦调用了第一个函数，就可以告诉链接器只加载库。这通常不是一件好事，但有一些罕见的用例，这是有道理的，比如有一个程序可以在你想要使用的库不可用的环境中使用。
不要过分担心动态库的开销。这是可以理解的，除非在极端情况下，否则根本不重要。在优化这些事情之前执行测量。