Unterschied zwischen statischen und gemeinsam genutzten Bibliotheken?

Lesezeit: 8 Minuten

Benutzer-Avatar
Mohit Deshpande

Was ist der Unterschied zwischen statischen und gemeinsam genutzten Bibliotheken?

Ich verwende Eclipse und es gibt mehrere Projekttypen, darunter statische Bibliotheken und gemeinsam genutzte Bibliotheken? Hat das eine einen Vorteil gegenüber dem anderen?

  • Wikipedia hat eine gute Beschreibung der Unterscheidung zwischen statischen, dynamischen und gemeinsam genutzten Bibliotheken.

    – Adam Holmberg

    15. April 2010 um 22:13 Uhr

Benutzer-Avatar
Petesch

Gemeinsam genutzte Bibliotheken sind .so-Dateien (oder in Windows .dll oder in OS X .dylib-Dateien). Der gesamte Code, der sich auf die Bibliothek bezieht, befindet sich in dieser Datei und wird von Programmen, die sie zur Laufzeit verwenden, referenziert. 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, der sich auf die Bibliothek bezieht, befindet sich in dieser Datei und wird zur Kompilierzeit direkt in das Programm eingebunden. Ein Programm, das eine statische Bibliothek verwendet, nimmt Kopien des Codes, den es verwendet, aus der statischen Bibliothek und macht ihn zu einem Teil des Programms. [Windows also has .lib files which are used to reference .dll files, but they act the same way as the first one].

Bei jeder Methode gibt es Vor- und Nachteile:

  • Gemeinsam genutzte Bibliotheken reduzieren die Codemenge, die in jedem Programm dupliziert wird, das die Bibliothek verwendet, und halten die Binärdateien klein. Es ermöglicht Ihnen auch, das gemeinsam genutzte Objekt durch eines zu ersetzen, das funktional gleichwertig ist, aber möglicherweise zusätzliche Leistungsvorteile bietet, ohne das Programm, das es verwendet, neu kompilieren zu müssen. Bei gemeinsam genutzten Bibliotheken fallen jedoch geringe zusätzliche Kosten für die Ausführung der Funktionen sowie Ladekosten zur Laufzeit an, da alle Symbole in der Bibliothek mit den Dingen verbunden werden müssen, die sie verwenden. Außerdem können gemeinsam genutzte Bibliotheken zur Laufzeit in eine Anwendung geladen werden, was der allgemeine Mechanismus zum Implementieren binärer Plug-in-Systeme ist.

  • Statische Bibliotheken erhöhen die Gesamtgröße der Binärdatei, aber das bedeutet, dass Sie keine Kopie der verwendeten Bibliothek mit sich führen müssen. Da der Code zur Kompilierzeit verbunden wird, fallen keine zusätzlichen Ladekosten zur Laufzeit an. Der Code ist einfach da.

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

  • „Ersetzen Sie das gemeinsame Objekt durch … funktional gleichwertig, aber möglicherweise [improve] Leistung”: insbesondere äquivalente anrufergerichtete Funktionalität bei der semantischen Verwendung der API (Anwendungsprogrammierschnittstelle: Funktionssignaturen und Variablen einschließlich Typen), aber die implementierungsseitige Funktionalität kann sich in mehr als der Leistung unterscheiden: z. B. Funktion protokolliert immer in Datei -> loggen Sie sich auch auf dem TCP-Server ein: Port erwartet in $MY_APP_LOG_SERVER.

    – Toni Delroy

    21. Februar 2014 um 6:19 Uhr

  • „Da der Code zur Kompilierzeit verbunden wird, fallen keine zusätzlichen Ladekosten zur Laufzeit an. Der Code ist einfach da.“ – ja und nein … es ist alles im ausführbaren Image, das bereit ist, eingelagert zu werden, wenn die Ausführung dies erfordert, aber – ausgehend von einer Situation, in der Ihr Programm nicht kürzlich genug ausgeführt wurde, um im Cache zu sein – mit gemeinsam genutzten Bibliotheken ist es möglich (manchmal wahrscheinlich oder sicher), dass das Betriebssystem, ein Treiber oder ein anderes laufendes Programm bereits dieselbe gemeinsam genutzte Bibliothek geladen hat, die Ihre App verwenden möchte. In diesem Fall befindet sie sich möglicherweise im Cache und Ihr Programm startet und läuft schneller.

    – Toni Delroy

    21. Februar 2014 um 6:40 Uhr


  • Was einige Leute nicht erwähnt haben, ist, dass der Compiler bei statischen Bibliotheken weiß, welche Funktionen Ihre Anwendung benötigt, und sie dann optimieren kann, indem er nur diese Funktionen einbezieht. Dies kann die Bibliotheksgröße massiv reduzieren, insbesondere wenn Sie nur eine wirklich kleine Teilmenge einer wirklich großen Bibliothek verwenden!

    – jduncanator

    25. Juli 2014 um 13:10 Uhr

  • Diese Antwort könnte besser organisiert sein. Es wäre hilfreich, Aufzählungslisten für Vor- und Nachteile oder eine Tabelle zu erstellen, um die Unterschiede in jeder Dimension aufzuzeigen, wo es einen Unterschied gibt.

    – ElefEnt

    24. Oktober 2016 um 21:52 Uhr

  • Wenn Sie dynamisch kompilieren, deklarieren Sie eine Abhängigkeit, die zur Laufzeit aufgelöst wird. Um diese Abhängigkeit zu erfüllen, müssen Sie entweder (a) eine Kopie der Bibliothek mit dem Programm mit sich führen oder (b) sicherstellen, dass die Bibliothek vor der Ausführung auf dem Zielsystem installiert ist. Dies bedeutet, dass die Bereitstellung des Programms komplizierter wird. Beim statischen Linken werden alle diese Abhängigkeiten zur Kompilierzeit in das Programm eingefügt, wodurch die Bereitstellung normalerweise auf eine einzige Datei reduziert wird.

    – Petesch

    8. November 2018 um 23:06 Uhr

Benutzer-Avatar
Paul Richter

Eine statische Bibliothek ist wie ein Buchladen, und eine gemeinsam genutzte Bibliothek ist wie … eine Bibliothek. Bei ersterem erhalten Sie Ihr eigenes Exemplar des Buches/der Veranstaltung zum Mitnehmen; Mit letzterem gehen Sie und alle anderen in die Bibliothek, um dasselbe Buch / dieselbe Funktion zu verwenden. Wer also die (gemeinsame) Bibliothek nutzen möchte, muss wissen, wo sie ist, denn man muss das Buch/die Funktion „holen“. Bei einer statischen Bibliothek gehört das Buch/die Funktion Ihnen, und Sie behalten es in Ihrem Zuhause/Programm, und sobald Sie es haben, ist es Ihnen egal, wo oder wann Sie es bekommen haben.

Benutzer-Avatar
GestapeltSchief

Vereinfacht:

  • Statisches Linken: eine große ausführbare Datei
  • Dynamisches Linken: eine kleine ausführbare Datei plus eine oder mehrere Bibliotheksdateien (.dll-Dateien unter Windows, .so unter Linux oder .dylib unter macOS)

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 hat zur Laufzeit keine Abhängigkeiten von der Bibliothek

Bei einer gemeinsam genutzten Bibliothek prü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 hat kein Konzept von statischen oder gemeinsam genutzten Bibliotheken – sie sind vollständig ein Implementierungsmerkmal.

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

Benutzer-Avatar
Tarski

Statische Bibliotheken werden als Teil einer Anwendung kompiliert, gemeinsam genutzte Bibliotheken hingegen nicht. Wenn Sie eine Anwendung verteilen, die von gemeinsam genutzten Bibliotheken abhängt, werden die Bibliotheken, z. dlls auf MS Windows müssen installiert werden.

Der Vorteil statischer Bibliotheken besteht darin, dass für den Benutzer, der die Anwendung ausführt, keine Abhängigkeiten erforderlich sind – er muss beispielsweise seine DLL oder was auch immer nicht aktualisieren. Der Nachteil besteht darin, dass Ihre Anwendung größer ist, da Sie sie mit allen erforderlichen Bibliotheken ausliefern.

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

  • DLL-Hölle, wie sie bekannt ist

    – Gheese

    1. November 2013 um 15:45 Uhr

  • “Statische Bibliotheken werden als Teil einer Anwendung kompiliert” … statische Bibliotheken werden als statische Bibliotheken kompiliert und als Teil einer Anwendung gelinkt

    – 463035818_ist_keine_Nummer

    12. Juli 2017 um 10:23 Uhr

Der bedeutendste Vorteil gemeinsam genutzter Bibliotheken besteht darin, dass nur eine Kopie des Codes in den Speicher geladen wird, unabhängig davon, wie viele Prozesse die Bibliothek verwenden. Bei statischen Bibliotheken erhält jeder Prozess seine eigene Kopie des Codes. Dies kann zu erheblicher Speicherverschwendung führen.

OTOH, ein Vorteil statischer Bibliotheken ist, dass alles in Ihrer Anwendung gebündelt ist. Sie müssen sich also keine Sorgen machen, dass der Kunde die richtige Bibliothek (und Version) auf seinem System verfügbar hat.

  • DLL-Hölle, wie sie bekannt ist

    – Gheese

    1. November 2013 um 15:45 Uhr

  • “Statische Bibliotheken werden als Teil einer Anwendung kompiliert” … statische Bibliotheken werden als statische Bibliotheken kompiliert und als Teil einer Anwendung gelinkt

    – 463035818_ist_keine_Nummer

    12. Juli 2017 um 10:23 Uhr

Benutzer-Avatar
Sandholz

Zusätzlich zu all den anderen Antworten ist eine Sache, die noch nicht erwähnt wurde, die Entkopplung:

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

Eine sehr große Software, die aus >300 Projekten (mit Visual Studio) besteht, meist als statische Bibliothek erstellt und schließlich alle in einer riesigen ausführbaren Datei verknüpft sind, endet mit den folgenden Problemen:

-Verbindungszeit ist extrem lang. Sie könnten am Ende mehr als 15 Minuten Link haben, sagen wir 10 Sekunden Kompilierzeit. – Einige Tools sind mit einer so großen ausführbaren Datei auf dem Knie, wie Tools zur Speicherprüfung, die den Code instrumentieren müssen. Sie könnten in das Erreichen von Grenzen geraten, die als Narren angesehen wurden.

Problematischer ist die Entkopplung Ihrer Software: In diesem realen Beispiel waren die Header-Dateien jedes Projekts von allen anderen Projekten aus erreichbar. Infolgedessen war es für einen Entwickler extrem einfach, Abhängigkeiten hinzuzufügen; Es ging nur darum, den Header einzufügen, denn der Link am Ende erlaubt es, Symbole zu finden. Es endet mit schrecklichen Fahrradabhängigkeiten und völligem Durcheinander.

Bei einer gemeinsam genutzten Bibliothek ist dies etwas zusätzliche Arbeit, da der Entwickler das Projekterstellungssystem bearbeiten muss, um die abhängige Bibliothek hinzuzufügen. Ich habe festgestellt, dass Shared-Library-Code tendenziell eine sauberere Code-API bietet.

1013560cookie-checkUnterschied zwischen statischen und gemeinsam genutzten Bibliotheken?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy