it-swarm.com.de

Unterschied zwischen statischen und gemeinsam genutzten Bibliotheken?

Was ist der Unterschied zwischen statischen und gemeinsam genutzten Bibliotheken?

Ich verwende Eclipse und es gibt verschiedene Projekttypen, darunter statische Bibliotheken und gemeinsam genutzte Bibliotheken. Hat einer einen Vorteil gegenüber dem anderen?

521
Mohit Deshpande

Freigegebene Bibliotheken sind .so-Dateien (oder in Windows-DLL- oder OS X-Dylib-Dateien). Der gesamte Code für die Bibliothek befindet sich in dieser Datei und wird von Programmen referenziert, die ihn zur Laufzeit verwenden. Ein Programm, das eine gemeinsam genutzte Bibliothek verwendet, verweist nur auf den Code, den es in der gemeinsam genutzten Bibliothek verwendet.

Statische Bibliotheken sind .a-Dateien (oder in Windows .lib-Dateien). Der gesamte Code für die Bibliothek befindet sich in dieser Datei und wird beim Kompilieren direkt mit dem Programm verknüpft. Ein Programm, das eine statische Bibliothek verwendet, entnimmt Kopien des verwendeten Codes aus der statischen Bibliothek und macht ihn zum Teil des Programms. [Windows hat auch LIB-Dateien, die zum Verweisen auf DLL-Dateien verwendet werden, aber sie verhalten sich genauso wie die erste].

Jede Methode hat Vor- und Nachteile.

Freigegebene Bibliotheken reduzieren die Menge des Codes, der in jedem Programm dupliziert wird, das die Bibliothek verwendet, und halten die Binärdateien klein. Sie können das gemeinsam genutzte Objekt auch durch ein funktional gleichwertiges Objekt ersetzen, das jedoch zusätzliche Leistungsvorteile bietet, ohne dass das Programm, das es verwendet, neu kompiliert werden muss. Für gemeinsam genutzte Bibliotheken fallen jedoch geringe zusätzliche Kosten für die Ausführung der Funktionen sowie Kosten für das Laden zur Laufzeit an, da alle Symbole in der Bibliothek mit den von ihnen verwendeten Dingen verbunden werden müssen. Darüber hinaus können gemeinsam genutzte Bibliotheken zur Laufzeit in eine Anwendung geladen werden. Dies ist der allgemeine Mechanismus zur Implementierung von binären Plug-In-Systemen.

Statische Bibliotheken vergrößern die Gesamtgröße der Binärdatei, bedeuten jedoch, dass Sie keine Kopie der verwendeten Bibliothek mitführen müssen. Da der Code zur Kompilierungszeit verbunden ist, fallen keine zusätzlichen Kosten für das Laden zur Laufzeit an. Der Code ist einfach da.

Persönlich bevorzuge ich gemeinsam genutzte Bibliotheken, verwende jedoch statische Bibliotheken, wenn sichergestellt werden muss, dass die Binärdatei nicht viele externe Abhängigkeiten aufweist, die möglicherweise schwer zu erfüllen sind, z. B. bestimmte Versionen der C++ - Standardbibliothek oder bestimmte Versionen der Boost C++ - Bibliothek.

707
Petesh

Eine statische Bibliothek ist wie ein Buchladen, und eine gemeinsam genutzte Bibliothek ist wie ... eine Bibliothek. Mit dem ersteren erhalten Sie Ihre eigene Kopie des Buches/der Funktion, die Sie mit nach Hause nehmen können. Mit letzterem gehen Sie und alle anderen in die Bibliothek, um dasselbe Buch/dieselbe Funktion zu verwenden. Jeder, der die (gemeinsam genutzte) Bibliothek nutzen möchte, muss wissen, wo sie sich befindet, denn Sie müssen das Buch/die Funktion "holen". Mit einer statischen Bibliothek gehört das Buch/die Funktion Ihnen, und Sie behalten es in Ihrem Heim/Programm, und sobald Sie es haben, ist es Ihnen egal, wo oder wann Sie es haben.

366
Paul Richter

Vereinfacht:

  • Statische Verknüpfung: Eine große ausführbare Datei
  • Dynamische Verknüpfung: eine kleine ausführbare Datei plus eine oder mehrere Bibliotheksdateien (DLL-Dateien unter Windows, SO unter Linux oder Dylib unter MacOS)
65
StackedCrooked

Bei einer statischen Bibliothek wird der Code vom Linker aus der Bibliothek extrahiert und zum Erstellen der endgültigen ausführbaren Datei an dem Punkt verwendet, an dem Sie Ihre Anwendung kompilieren/erstellen. Die endgültige ausführbare Datei ist zur Laufzeit nicht von der Bibliothek abhängig

Bei einer gemeinsam genutzten Bibliothek überprüft der Compiler/Linker, ob die Namen, mit denen Sie verknüpfen, in der Bibliothek vorhanden sind, wenn die Anwendung erstellt wird, verschiebt ihren Code jedoch nicht in die Anwendung. Zur Laufzeit muss die gemeinsam genutzte Bibliothek verfügbar sein.

Die Programmiersprache C selbst kennt weder statische noch gemeinsam genutzte Bibliotheken - sie sind vollständig eine Implementierungsfunktion.

Persönlich bevorzuge ich statische Bibliotheken, da dies die Softwareverteilung vereinfacht. Dies ist jedoch eine Meinung, über die in der Vergangenheit viel (bildliches) Blut vergossen wurde.

32
anon

Statische Bibliotheken werden als Teil einer Anwendung kompiliert, gemeinsam genutzte Bibliotheken jedoch nicht. Wenn Sie eine Anwendung verteilen, die von gemeinsam genutzten Bibliotheken abhängt, werden die Bibliotheken, z. dll's unter MS Windows müssen installiert sein.

Der Vorteil von statischen Bibliotheken besteht darin, dass für den Benutzer, der die Anwendung ausführt, keine Abhängigkeiten erforderlich sind - z. Sie müssen ihr DLL nicht aktualisieren. Der Nachteil ist, dass Ihre Anwendung größer ist, da Sie sie mit allen benötigten Bibliotheken ausliefern.

Gemeinsam genutzte Bibliotheken führen nicht nur zu kleineren Anwendungen, sondern bieten dem Benutzer auch die Möglichkeit, eine eigene, möglicherweise bessere Version der Bibliotheken zu verwenden, anstatt sich auf eine zu verlassen, die Teil der Anwendung ist

28
Tarski

Der wichtigste Vorteil von gemeinsam genutzten Bibliotheken besteht darin, dass nur eine Kopie des Codes im Speicher geladen ist, unabhängig davon, wie viele Prozesse die Bibliothek verwenden. Bei statischen Bibliotheken erhält jeder Prozess eine eigene Kopie des Codes. Dies kann zu einer erheblichen Speicherverschwendung führen.

OTOH, ein Vorteil von statischen Bibliotheken ist, dass alles in Ihrer Anwendung gebündelt ist. Sie müssen sich also keine Sorgen machen, dass der Client die richtige Bibliothek (und Version) auf seinem System zur Verfügung hat.

17
Jasmeet

Neben all den anderen Antworten ist eine Sache, die noch nicht erwähnt wurde, das Entkoppeln:

Lassen Sie mich über einen realen Produktionscode sprechen, mit dem ich mich befasst habe:

Eine sehr große Software, die aus mehr als 300 Projekten (mit Visual Studio) besteht, meist als statische Bibliothek erstellt und schließlich alle in einer großen ausführbaren Datei verknüpft wird, führt zu folgenden Problemen:

-Link-Zeit ist extrem lang. Es kann sein, dass Sie mehr als 15 Minuten Verbindungszeit benötigen, zum Beispiel 10 Sekunden Kompilierungszeit. Einige Tools haben eine so große ausführbare Datei, wie Tools zur Speicherüberprüfung, die den Code instrumentieren müssen. Sie könnten an Grenzen stoßen, die als Narren galten.

Problematischer ist die Entkopplung Ihrer Software: In diesem realen Beispiel waren die Header-Dateien aller Projekte von allen anderen Projekten aus erreichbar. Infolgedessen war es für einen Entwickler äußerst einfach, Abhängigkeiten hinzuzufügen. Es ging nur darum, den Header einzuschließen, da der Link am Ende immer wieder Symbole findet. Es endet mit schrecklichen Fahrradabhängigkeiten und völligem Durcheinander.

Mit einer gemeinsam genutzten Bibliothek ist es ein bisschen mehr Arbeit, da der Entwickler das Projekterstellungssystem bearbeiten muss, um die abhängige Bibliothek hinzuzufügen. Ich habe festgestellt, dass gemeinsam genutzter Bibliothekscode tendenziell eine sauberere Code-API bietet.

6
sandwood
-------------------------------------------------------------------------
|  +-  |    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  |                                     |
-------------------------------------------------------------------------
0
snr