Statische gegen dynamische Bibliotheken

  • C++

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von jvbsl.

    @ichduersie Wenn Du mehrere eigene Exen und DLLs in einer Projektmappe hast und alle Dateien werden gemeinsam installiert, kann man dynamische Runtime-Libs nehmen.
    In praktisch allen anderen Fällen empfehle ich statische Runtime-Libs.
    DLLs selbst kann man statisch an die Exe linken, wenn die Anzahl niedrig ist. Ist sie hoch, lieber dynamisch.
    Problematisch wird es besonders bei Runtime-Libs, wenn nicht klar ist, was auf dem Zielrechner installiert ist, da empfehlen sich statische Runtime-Libs.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich geh jetzt mal von C/C++ aus.
    Statisch:
    +Geringfügig schnellere Ladezeit, evtl. schnellere Funktionsaufrufe
    - Ausgabe Executable ist größer.
    - Kann nicht getrennt ausgeliefert werden.
    +- Von sich aus lauffähiges Einzelprogramm, das aber nur auf einer sehr spezifischen Zielplattform lauffähig sein wird.
    Gibt in aller Regel keinen Sinn statisch zu linken. Macht man aber gerne für kleine Libraries, da es dort eher egal ist.
    Dynamisch:
    + Muss Libraries ggf. nicht mitliefern(für Lnx sind viele über die einfachen Paketverwaltungen ganz easy zu installieren).
    + Für jedes System die passende Library auf dem System installiert/mitlieferbar
    + Kleines Ausgabeprogramm
    + Libraries/Programm einzeln austauschbar
    - Ladevorgang geht unmerkbar länger Aufrufe können einen Lookup-schritt benötigen(jenach Executable Format und OS, aber idR wird das einfach über ein Offset gemacht also lächerlich wenig Aufwand.).
    - Zusätzliche Abhängigkeit(aber ganz ehrlich, dann lieferst du die DLL halt im selben Verzeichnis mit)

    Wenn es einem wirklich dann um Performance geht, dann sollte man sowieso Header-Only-Libraries verwenden, da die dann auch inlined werden können und der Kompiler sonstige Optimierungen vornehmen kann, da er über alles bescheid weiß und selbst entscheiden kann. Natürlich mit den selben Problemen wie die statisch gelinkt, jedoch sind die Performance unterschiede jenach Anwendung immens(vorallem bei vielen Aufrufen)
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    ichduersie schrieb:

    Wie meinst du das?
    In C++ gibt es immer 2 Dateien: Eine *.dll und eine *.lib.
    Die DLL ist sozusagen eine Exe, das wäre die dynamisch zu ladende Bibliothek,
    die Lib ist eine Obj-Datei, die kann man an eine DLL oder eine Exe dranlinken, das wäre die statische Variante.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:

    [in Windows] gibt es immer 2 Dateien

    *nix machen das mit je einer datei .a für statisch und .so/.dynlib für dynamisch.

    Auch für Windows gibt es Compiler, die .a unterstützen. Aber für .dll braucht man auf win immer eine zugehörige .lib die zusätzliche informationen enthält. Diese kann man theoretisch auch aus einer dll erzeugen, aber das funktioniert auch eher schlecht als recht.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    @RodFromGermany: Das ist mir klar. Du kannst einer DLL ja auch einen Einstiegspunkt geben und mit rundll dann diesen aufrufen.
    @jvbsl: Du kannst die LIB natürlich auch mit LoadLibrary(), GetProcAddress() und FreeLibrary() mMn unelegant und aufwändig umgehen :D
    Deine Argumentation zeigt aber einen Nachteil der DLL nicht auf. Wenn man unabhängig von Programmen eine Bibliothek entwickelt, d ann kann man ja nicht einfach so alte Funktionen rausschmeißen und ersetzen, da man dann ja Gefahr läuft, dass etwaige Programme nicht mehr funktionieren. Gleiches gilt auch für Bibliotheken, die nur als Ressourcenquelle genutzt werden. Und das bläht die Bibliothek dann natürlich unnötig auf. Gut, wenn man des mit dem Speicher, der verschwendet wird, wenn jedes Programm statisch linkt, in Relation setzt, ist das vertretbar. Aber du musst dann halt mit dem Legacycode leben.
    Ühm deine Argumentation, wenn man was rausschmeißt oder entsprechend ändert, dass das Programm nicht mehr funktioniert gilt für statische Libraries genau so, also das ist wohl das kleinste Argument. Außerdem macht man dann idR breaking changes nur bei major versionen und lässt dann die funktionen zumindest Kompatibilitätszwecken gleich. Dann kommt in den Library Namen einfach die Major version und wenn man gegen diese dann linkt. Dann wird auf dem Zielsystem eben nach dieser Major Version gesucht. D.h. wenn jemand tatsächlich etwas entsprechend älteres braucht muss er sich halt natürlich die alte DLL holen. Ergibt aber auch Sinn.

    LoadLibrary etc. ist denke ich sowieso eher für Plugins u.ä. gedacht. Nicht für das laden einer Library, die sowieso sicher dazu gehört. In .Net kann es da dann denk ich schon eher Sinn ergeben. Kann man jedoch oft ebenfalls umgehen.
    Oder man umgeht die .lib indem man auf Linux geht, ist mMn sowieso sinnvoller :P
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    ichduersie schrieb:

    Du kannst die LIB natürlich auch mit LoadLibrary(), GetProcAddress() und FreeLibrary() mMn unelegant und aufwändig umgehen
    Genau das brauchst Du z.B. für ein C++-Plugin-System.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @ichduersie bisher hatte ich mehr Probleme für Windows Treiber zu finden als für Linux, wobei auf Linux vieles oftmals out of the box lief. Also persönlich kann ich das null bestätigen.(Auf Win 64 Bit laptop vorinstalliert 32 Bit system wollte ich 64 Bit Windows instalieren. Bis heute noch nicht alle treiber gefunden. Viele Grafikkartentreiber etc.). Gab auch schon, dass ich anhand der HW-ID auf Win keine treiber gefunden hatte. Linux-Live Disk lsusb, danach gegooglet, somit den Namen rausbekommen und konnte dann auch die Treiber für Windows finden :D

    Aber das wird jetzt hier zu viel Offtopic :D

    RodFromGermany schrieb:

    Genau das brauchst Du z.B. für ein C++-Plugin-System.

    jvbsl schrieb:

    LoadLibrary etc. ist denke ich sowieso eher für Plugins u.ä. gedacht.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---