C プログラミングでは、単一のソース コード ファイルが最終的なメモリ フットプリントにどれだけ貢献しているかを判断する方法はありますか?
ソースファイルtest1.c、test2.c、test3.cなどで構成される単純な C プログラムを想定してみましょう。環境は Linux でコンパイラはgccです。
objdumpと を使用すると、総フットプリントと、バイナリが、、およびセグメントreadelfにどのように分散されているかを確認できます。しかし、 test1.cごとに生成されるバイナリ コードの量、test2.cごとに生成されるバイナリ コードの量などを確認することは可能ですか?.text.data.bss
質問のタイトルと内容が違う方向を指しているようです。
アプリケーションが実行時にソース コード ファイルごとに必要とするメモリの量を質問する場合、一般的には決定できません。制御できない外部出力に依存する可能性があります。ただし、再帰の深さ (スタックが必要) または実行時の情報 --inputs に確実に依存するため、必要な動的メモリの量がわからない定数のみを使用する場合を除きます。
あなたの質問が、最終的なバイナリのコードが各ファイルからどれだけ得られるかということであれば、十分に興味があるかどうかがわかります。ゼロエス近似は.o、コンパイラが生成するファイルのサイズをチェックしています。リンカーはリンク段階で未使用のシンボルをオブジェクト ファイルから削除できるため、この概算はかなり不適切です。次に、最終的な実行可能ファイルのシンボルをより洗練して検査し、オブジェクト ファイルのそれぞれでそれらのシンボルを探すことができます。これにより、はるかに優れた情報が提供されますが、さらに多くの作業が必要になります。
いいえ、ありません。ほとんどのメモリは実行時に割り当てられ、ソース ファイルを調べても推測できません。たとえば、次のコードがあるとします。
int n;
cin >> n;
char * p = new char[n];
ソースを調べても、プログラムの実行時に割り当てられるメモリの量を知る方法はありません。
それは非常に奇妙な質問です。額面どおりに考えると、コンパイル時に生成される .obj/.o ファイルを確認するだけで済みます。これらは、コードに関して、各モジュールのサイズになります。
ただし、これには、プログラムの実行時に割り当てられるメモリは考慮されていません。また、現在実行されていないプログラムの部分が必ずしもメモリに保持されているとは限らないことも考慮されていません。
大量のコードを記述してすべてのメモリを占有することを懸念している場合でも、心配する必要はありません。そんなことありえない。:)
いいえ、基本的にありません。
たとえば、両方に文字列 を含む 2 つのソース ファイルがあるとします"Hello, world\n"。ほとんどのリンカーは、これらの文字列リテラルを折りたたむことができます。文字列リテラルが 1 つだけ残っていますが、これはどのように説明する必要がありますか? 関数でも同様のことが起こります。たとえば、std::vector<int>::push_back(int)とstd::vector<long>::push_back(long)は同じ実行可能コードを生成し、リンカーはインスタンスを 1 つだけ残す場合があります。
さらに、vector<int>::push_back(int)もう一度考えてみてください。<vector>実際には、多くの .cpp ファイルに含まれるヘッダーから来ています。ただし、コンパイラは通常、それをまったく記録しませんtest1.o。test1.cpp に含まれるすべてのものも含まれます。