6

私が考えることができる唯一の利点は、コンパイルの速度です。どちらの場合も最終結果 (バイナリ サイズと速度) は同じになるはずです (もちろん、静的ライブラリが最適化なしでコンパイルされた場合を除きます)。

また、いくつかの参照をいただければ幸いです。

更新:この質問は、小規模なサードパーティのオープン ソース ライブラリをプロジェクトに含める必要があったときに発生しました。ある開発者は、(ソース ファイルをコピーするだけでなく) プリコンパイルされた静的ライブラリを含めると、アプリのパフォーマンスが向上すると述べています。これが事実であるべき理由はわかりません。

問題は、プリコンパイルされたライブラリを含めると、最終的なアプリのパフォーマンスが本当に向上するかということです。

4

1 に答える 1

3

サードパーティのライブラリについて話している場合、サードパーティのライブラリのいくつかの利点は次のとおりです。ソースコードをリリースする必要がない、(潜在的に)エンド開発者にとってインストールが簡単になる...正しく行われていません (シンボルを修正せずに他のオープン ソース プロジェクトにリンクし、間違ったアーキテクチャがサポートされています)。

自分のコードだけを意味する場合は、自分で頭痛の種を作っているようです。ファイルが変更されていない場合、ファイルは既にディスク (.o) でコンパイルされており、すべてをクリーン/再構築しない限り、コンパイラはそれらを再構築する必要はありません。そのため、コンパイル速度が向上しない可能性があります。

いずれにしても - はい、出力は同じでなければなりません。静的にリンクされたライブラリは、直接リンクしていたのと同じ .o ファイルの単なるコレクションです。

編集：

特に .o と .a の速度に対処する - .a は、開発中のパッケージ化を容易にするための .o ファイルの集まりです。リンクされると、結果は同じになります。確認するために簡単なサニティテストを行いました：

$ cat a.c
#include <stdio.h>

extern char *something();

int main()
{
    printf("%s", something());
    return 0;
}
$ cat b.c
char *something()
{
    return "something fancy here\n";    
}

$ gcc -c -o a.o a.c
$ gcc -c -o b.o b.c
$ gcc -o foo1 a.o b.o
$ ar -r b.a b.o
ar: creating archive b.a
$ gcc -o foo2 a.o b.a
$ cmp foo1 foo2

これで、.o と .a をリンクすることで、同一のバイナリが完成しました。

静的ライブラリの代わりに動的ライブラリを使用すると、パフォーマンスがわずかに低下します (シンボルが検索された場合のみだと思います)。おそらくこれは、他の開発者が言及していたことであり、静的ライブラリは動的ライブラリよりもわずかに高速です。

于 2013-02-14T15:55:30.227 に答える