每个源文件的C / C ++内存占用量

Question

在C编程中，有没有办法确定单个源代码文件对最终内存占用量的贡献？

让我们假设一个简单的C程序，包含源文件 test1.c ， test2.c ， test3.c ，等等上。环境是Linux和编译器 gcc 。

可以看到objdump和readelf，查看总体足迹以及二进制文件在.text，.data和.bss细分中的分布情况。但是有可能看到每个 test1.c 生成多少二进制代码，每个 test2.c 等多少？

Answer 1

不，没有。大多数内存是在运行时分配的，无法从检查源文件中推断出。例如，给定此代码：

int n;
cin >> n;
char * p = new char[n];

检查源代码无法告诉您在执行程序时将分配多少内存。

Answer 2

问题标题和内容似乎指向不同的方向。

如果您的问题是您的应用程序在运行时每个源代码文件需要多少内存，这在一般情况下是不可判定的。它可能依赖于您无法控制的外部输出，除非只使用常量，您无法知道递归的深度（需要堆栈）或需要多少动态内存，因为这些肯定取决于运行时信息--inputs。 / p>

如果您的问题是最终二进制文件中的代码来自每个文件，您可以看到是否有足够的兴趣。零eth近似是检查编译器生成的.o文件的大小。这种近似是相当糟糕的，因为链接器可以在链接阶段从目标文件中删除未使用的符号。然后你可以变得更加漂亮并检查最终可执行文件中的符号，并在每个目标文件中查找这些符号。这将提供更好的信息，但需要更多的工作。

Answer 3

这是一个非常奇怪的问题。以表面值为例，您只需要查看编译时生成的.obj / .o文件。就代码而言，这些将是每个模块的大小。

但是，这并不考虑在程序运行时分配的任何内存。它也没有考虑到当前没有运行的程序部分不一定保存在内存中。

如果您担心编写大量代码并占用所有内存，请不要担心。它不可能发生。 ：）

Answer 4

不，从根本上说不是。

例如，取两个包含字符串"Hello, world\n"的源文件。大多数链接器都能够折叠这些字符串文字。只剩下一个字符串文字，应如何计算？甚至对于功能也会发生类似的事情。例如，std::vector<int>::push_back(int)和std::vector<long>::push_back(long)可能生成相同的可执行代码，并且链接器可能只留下一个实例。

此外，再次考虑vector<int>::push_back(int)。它实际上来自标题<vector>，它将包含在许多.cpp文件中。但编译器通常根本不记录 - test1.o包含test1.cpp包含的所有内容。