静的ライブラリと共有ライブラリの違いは？
静的ライブラリと共有ライブラリの違いは何ですか？
Eclipseを使用していますが、静的ライブラリと共有ライブラリを含むいくつかのプロジェクトタイプがありますか？一方が他方よりも有利な点はありますか？
共有ライブラリは、.so（またはWindowsの.dll、またはOS Xの.dylib）ファイルです。ライブラリに関連するすべてのコードはこのファイルにあり、実行時にそれを使用するプログラムによって参照されます。共有ライブラリを使用しているプログラムは、共有ライブラリで使用しているコードを参照するだけです。
静的ライブラリは、.a（またはWindowsの.lib）ファイルです。ライブラリに関連するすべてのコードはこのファイルにあり、コンパイル時にプログラムに直接リンクされています。静的ライブラリを使用しているプログラムは、静的ライブラリから使用しているコードのコピーを取り、それをプログラムの一部にします。 [Windowsにも.dllファイルを参照するために使用される.libファイルがありますが、最初のファイルと同じように機能します]。
各方法には長所と短所があります。
共有ライブラリは、ライブラリを利用する各プログラムで複製されるコードの量を減らし、バイナリを小さくします。また、共有オブジェクトを機能的に同等のものと置き換えることもできますが、それを利用するプログラムを再コンパイルする必要なしにパフォーマンス上の利点が追加される可能性があります。ただし、共有ライブラリは、ライブラリ内のすべてのシンボルをそれらが使用するものに接続する必要があるため、関数の実行にわずかな追加コストと実行時のロードコストがかかります。さらに、共有ライブラリは実行時にアプリケーションにロードできます。これは、バイナリプラグインシステムを実装するための一般的なメカニズムです。
静的ライブラリはバイナリ全体のサイズを大きくしますが、使用されているライブラリのコピーを持ち歩く必要がないことを意味します。コードはコンパイル時に接続されるので、追加の実行時ロードコストはありません。コードは単にそこにあります。
個人的には共有ライブラリを好みますが、特定のバージョンのC++標準ライブラリや特定のバージョンのBoost C++ライブラリなど、満たすことが難しい外部依存関係がバイナリに含まれないようにする必要がある場合は静的ライブラリを使用します。
静的ライブラリは書店のようなもので、共有ライブラリは...図書館のようなものです。前者で、あなたは家に持ち帰るために本/機能のあなた自身のコピーを手に入れます。後者では、あなたと他の誰もが同じ本/機能を使うために図書館に行きます。そのため、（共有）ライブラリを使用したい人は誰でも、その本や機能を "手に入れ"なければならないので、それがどこにあるのかを知る必要があります。静的なライブラリでは、本/機能はあなたが所有するものであり、あなたはそれをあなたの家/プログラム内に保管します、そして一度あなたがそれを手に入れたら、あなたはそれをどこで、いつ手に入れました。
簡体字
- 静的リンク：1つの大きな実行可能ファイル
- 動的リンク：小さな実行可能ファイルと1つ以上のライブラリファイル（Windowsの場合は.dllファイル、Linuxの場合は.so、macOSの場合は.dylib）
静的ライブラリの場合、コードはリンカによってライブラリから抽出され、アプリケーションをコンパイルまたは構築した時点で最終的な実行可能ファイルを構築するために使用されます。最終的な実行可能ファイルは、実行時にライブラリに依存しません。
共有ライブラリの場合、コンパイラ/リンカは、アプリケーションの構築時にリンク先の名前がライブラリに存在することを確認しますが、それらのコードをアプリケーションに移動しません。実行時には、共有ライブラリが利用可能でなければなりません。
Cプログラミング言語自体には、静的ライブラリや共有ライブラリの概念はありません。これらは完全に実装機能です。
個人的には、ソフトウェア配布が簡単になるので、静的ライブラリを使用することをお勧めします。しかし、これは過去にどれだけの（比喩的な）血が流されたかについての意見です。
静的ライブラリはアプリケーションの一部としてコンパイルされますが、共有ライブラリはそうではありません。あなたが共有ライブラリに依存するアプリケーションを配布するときは、ライブラリ、例えば。 MS Windowsにdllをインストールする必要があります。
静的ライブラリの利点は、アプリケーションを実行しているユーザーに依存関係が必要ないことです。彼らは何でも彼らのDLLをアップグレードする必要はありません。欠点は、必要なすべてのライブラリと一緒に出荷されるため、アプリケーションのサイズが大きくなることです。
より小さなアプリケーションにつながるだけでなく、共有ライブラリはユーザーに、アプリケーションの一部であるライブラリに頼るのではなく、独自の、おそらくより良いバージョンのライブラリを使用する機能を提供します
共有ライブラリの最大の利点は、ライブラリを使用しているプロセスの数にかかわらず、メモリにロードされるコードのコピーが1つだけであることです。静的ライブラリの場合、各プロセスは独自のコードのコピーを取得します。これはかなりのメモリの浪費につながる可能性があります。
OTOH、静的ライブラリの利点は、すべてがアプリケーションにバンドルされていることです。したがって、クライアントが自分のシステムで利用可能な正しいライブラリ（およびバージョン）を持つことを心配する必要はありません。
他のすべての答えに加えて、まだ言及されていないことの1つはデカップリングです。
私が扱ってきた、実世界の生産コードについて話させてください。
300以上のプロジェクト（ビジュアルスタジオを含む）で作られた非常に大きなソフトウェアは、ほとんどがスタティックライブラリとしてビルドされ、最終的にはすべて1つの巨大な実行可能ファイルにリンクされます。
- リンク時間は非常に長いです。 15分以上のリンクが必要になるかもしれません。たとえば、コンパイル時間が何十秒にも及ぶ場合があります。コードを計測する必要があるメモリチェックツールのように、いくつかのツールには大きな実行可能ファイルがあります。あなたは愚か者と見られてきた限界に達することに陥るかもしれません。
より現実的な例では、すべてのプロジェクトのヘッダーファイルは他のどのプロジェクトからもアクセスできませんでした。結果として、ある開発者が依存関係を追加することは非常に簡単でした。最後のリンクはシンボルを見つけるためのものです。それはひどいサイクリング依存関係と完全な混乱によって終わります。
共有ライブラリでは、開発者がプロジェクトビルドシステムを編集して依存ライブラリを追加する必要があるため、少し手間がかかります。私は、共有ライブラリコードがよりクリーンなコードAPIを提供する傾向があることを観察しました。
-------------------------------------------------------------------------
| +- | Shared(dynamic) | Static Library (Linkages) |
-------------------------------------------------------------------------
|Pros: | less memory use | an executable, using own libraries|
| | | ,coming with the program, |
| | | doesn't need to worry about its |
| | | compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of | bigger memory uses |
| | libraries may be altered | |
| | subject to OS and its | |
| | version, which may affect| |
| | the compilebility and | |
| | runnability of the code | |
-------------------------------------------------------------------------