1

別の開発者と議論があります。Dynamic Link と Static Link のどちらかで解決したいと思います。

理論的には：

100 個の関数を含むライブラリがあり、それぞれにかなりの量のコードが含まれているとします。

int A()
int B()
int C()
..
..and so on...

そして、あなたのアプリケーションはそれらの 1 つだけを呼び出したり、依存したりします。

自由に使える方法は 2 つあります。

  1. ライブラリをダイナミック リンク ライブラリとしてビルドする
  2. ライブラリを静的にリンクされたライブラリとしてビルドする

私の同僚は、静的ライブラリをアプリケーションにリンクすると、コンパイラ/リンカーは99 個の未使用関数のコードを実行可能ファイルに追加しないと主張しています。私はそう主張します。このシナリオの唯一の利点は、実行可能ファイルが 1 つであることと、アプリケーションと共にライブラリを配布する必要がないことですが、動的にリンクされたライブラリ アプローチを使用した場合、サイズに大きな違いはありません。

誰が正しいですか？

4

2 に答える 2

3

これは、コードの編成方法と、使用するコンパイラーフラグの組み合わせによって異なります。

古典的で単純なモデルに従って、リンカーは、シンボル参照を満たすためにライブラリ内の必要なオブジェクトファイルをリンクします。したがって、A（）、B（）、およびC（）がそれぞれ異なるオブジェクトファイルで定義されている場合、実際に使用したシンボルを含むオブジェクトファイルのみがプログラムにリンクされます（プログラムが他の1つ以上に依存している場合を除きます。この場合、リンカはそれらの参照を満たすオブジェクトファイルも検索します。繰り返し、すべてを満足させるか、満足できないものを見つけるまで（その時点で、標準の「未解決の外部XXX」エラーメッセージが表示されます）。

最近では、ほとんどのコンパイラは、個別のオブジェクトファイルを作成するために個別のソースファイルに関数を配置しなくても、関数を個別の「モジュール」に「パッケージ化」できます。詳細はさまざまですが、最終的な実行可能ファイルを最小限に抑えるために、各ソースファイルをできるだけ小さくする必要性を減らす（またはなくす）ことができます。

つまり、結論としては、少なくともほとんどの場合、彼は正しく、あなたは間違っています。

于 2013-01-11T21:15:41.227 に答える
2

場合によります ：-）

各関数を独自のソースファイルに配置するか、/ Gyコンパイルオプションを使用すると、各関数は静的ライブラリの個別のセクションにパッケージ化されます。

その後、リンカは必要に応じてそれらを取得し、実際に呼び出される関数のみを含めることができます。

于 2013-01-11T21:15:39.703 に答える