Unterschied zwischen statischen und gemeinsam genutzten Bibliotheken?

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?

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.

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.

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.

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

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.

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.