在 C 编程中，有没有办法确定单个源代码文件对最终内存占用的贡献是多少？
让我们假设一个简单的 C 程序由源文件 test1.c、test2.c、test3.c 等组成在。环境是Linux和编译器gcc。
使用objdump 和readelf 可以看到总占用空间以及二进制文件在.text、.data 和.bss 段中的分布情况。但是是否有可能查看每个 test1.c 生成多少二进制代码，每个 test2.c 生成多少等？
【问题讨论】：
不，没有。大多数内存是在运行时分配的，不能从检查源文件中推断出来。例如，给定以下代码：
int n;
cin >> n;
char * p = new char[n];
检查源代码无法告诉您程序执行时将分配多少内存。
【讨论】：
问题的标题和内容似乎指向不同的方向。
如果您的问题是您的应用程序在运行时每个源代码文件需要多少内存，那通常是无法确定的。它可能取决于您无法控制的外部输出，除非仅使用常量，否则您无法知道递归的深度（需要堆栈）或需要多少动态内存，因为这些肯定取决于运行时信息 --inputs。
如果您的问题是最终二进制文件中有多少代码来自每个文件，您可以看看您是否有足够的兴趣。零 eth 近似值是检查编译器生成的 .o 文件的大小。该近似值相当糟糕，因为链接器可以在链接阶段从目标文件中删除未使用的符号。然后，您可以更有趣地检查最终可执行文件中的符号，并在每个目标文件中查找这些符号。这将提供更好的信息，但需要更多的工作。
【讨论】：
这是一个非常奇怪的问题。从表面上看，您只需要查看编译时生成的 .obj/.o 文件。就代码而言，这些将是每个模块的大小。
但是，这并没有考虑程序运行时分配的任何内存。它也没有考虑到当前未运行的程序部分不一定保存在内存中。
如果您担心编写大量代码并且会占用您所有的内存，请不要担心。这不可能发生。 :)
【讨论】：
不，基本上不是。
例如，获取两个都包含字符串"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 包含的所有内容。
【讨论】：