Verständnis frage zu DLL ???
-
Nein, eine alleinstehende Headerdatei nützt dir nicht sehr viel (und wenn sich im Header etwas ändert, mußt du trotzdem alle Programme neu compilieren). Und bei einer normalen LIB müssen Anwenderprogramme zumindest neu gelinkt werden.
-
Hallo
Nein, die Unterschiede sind fundemental. (Btw. ist es nicht korrekt Header mit DLLs zu vergleichen... zu dem Header gehört mindestens eine Implementationsdatei)
Nehmen wir mal an du hast einen Funktionskomplex Func, den du in drei Programmen P1, P2 und P3 verwenden willst. Du hast also die Wahl aus Func eine DLL zu machen und die von Px aus dynamisch oder statisch zu linken. Oder du bindest Func direkt in Px ein.
Direktes Einbinden hat zu Folge das jede Änderung von Func das Kompilieren von allen Px zur Folge hat. Auslagern in DLL erlaubt aber bei einer reinen Implementationsänderung nur die DLL neu zu kompiliren. Px können unverändert auf die neue DLL zugreifen.Desweiteren sind DLLs unverzichtbar wenn zwischen verschiedenen Sprachen ausgelagert werden soll. Deinen C++ Header kannst du nicht in ein Java-Projekt einbinden... eine DLL mit C-Interface schon.
bis bald
akari
-
Du hast die Unterschiede zwischen Headerdatei und DLL wohl gerade völlig durcheinandergebracht:
Eine DLL ist eine Bibliothek die compilierten Code enthält. Um die DLL in ein Programm zu laden, brauchst Du die Headerdatei trotzdem (oder eine Schnittstellenbeschreibung, aus der Du selbst einen Header erstellst). Du brauchst aber den Quellcode der DLL nicht herausgeben, wenn Du z.B. jemandem ein Programmmodul zur Verfügung stellen musst.Von daher: Header brauchst Du immer (in irgendeiner Form). Die Funktionen selbst kannst Du als Quelldatei mit deinem Projekt übersetzen lassen oder fertig als DLL vorliegen haben.
-
Naja, ich kann den Sourcecode aber auch in eine *.LIB "verstecken". Also das ist nun nicht gerade der Vorteil einer DLL. Sorry, aber die nenneswerten Vorteile wurden hier nicht genannt. DLLs machen meiner Meinung nur in wenigen Anwendungsszenarien sinn. Normalerweise fahre ich mit LIBs genauso gut. Ich kann mein Programm auch ohne DLL aufteilen, halt in LIBs. Der einzige Vorteil der DLLs ist meiner Meinung nach, das der Speicher dadurch geschont wird, das der Code nur einmal vorhanden ist. Aber selbst das geht nur, wenn die DLLs systemweit erreichbar sind, und nicht wie bei vielen Programmen im jeweiligen Programmverzeichnis liegen (das ist der größte Unsinn einer DLL-Nutzung!). Wenn dann bitte die DLLs auch in einem Zielordner ablegen, wo jedes Programm einen Nutzen davon hat. So wie es z.B. die GTK-Runtime macht. DAS macht Sinn. Die GTK-Runtime ist mehrere MB groß, da macht DLLs sinn. Und wenn ich mehrere GTK-Programme starte, rentiert sich das mit dem Speicherverbrauch.
Aber man kann das nicht pauschalisieren, das DLLs immer Sinn machen. Ich entwickle gerade ein Grafikprogramm. Habe mein Projekt in mehrere Unterprojekte (Libs) aufgeteilt. Erstelle aber diese als *.LIBs, weil beim Linken das Programm gerade mal 400 KByte groß wird. Am Ende wird das Programm vielleicht 1 bis 4 MByte groß als EXE sein. Da lohnen sich DLLs meines Erachtens nicht die Bohne. Natürlich hat jemand vielleicht eine Software die einem anderen Context eingesetzt werden muß, und wo man von DLLs profitieren kann. Z.B. kann ich mir bei Server-Software vorstellen, das wenn mehrere/viele Instanzen davon gestartet werden, am Ende DLLs sich beim Speicherverbrauch sehr gut rentieren. Keine Frage! Meine Benutzer werden aber im Normalfall nur eine Instanz von dem Grafikprogramm starten.
Update: auch hier muß man vielleicht unterscheiden, für wen die Libs sind. Werden diese, wie GTK, von vielen fremden Programmen genutzt? Da kann sich das Updaten von nur diesen GTK-DLLs lohnen. Macht Sinn. Aber meine eigenen Libs, die ich nur für mich entwickele... da kann ich auch die EXE ganz updaten. Wobei dann die oberen Anwendungsszenarien mit dazu kommen. Man sollte nicht die Kriterien einzeln betrachten.
Tobi! Was entwickelst du denn so für Programme? Weil ich würde mich nicht verrückt machen lassen, so nach dem Motto "Nur Programme mit DLLs sind gute Programme".
-
Ich bin Abiturient und stecke im 2.Semester, ich bin also noch kein Entwickler in dem Sinne, ich bringe mir das hier alles nur shcon mal mit eigenstudium bei, und schreibe hier und da mal nen kleines Programm um die verschiedenen Anwendungsweisen mal gehabt zu haben, doch letztendlich möchte ich auch wissen wieso das so ist und deswegen der post.
also meines erachtens sind DLL nur speicher schonend weil in ihnen eine schon komplett übersetzte Funktion enthalten ist oder wie? so waere es auch besser variablen in DLL zu packen weil die dann auch kein Speicher fressen oder wie?Gruß Tobi.
-
Nein, Variablen werden natürlich für jedes Programm extra Speicher verbrauchen. Bei dem Speicherverbrauch durch DLLs geht es nur um den Programmcode.
-
Artchi schrieb:
...wenn die DLLs systemweit erreichbar sind, und nicht wie bei vielen Programmen im jeweiligen Programmverzeichnis liegen (das ist der größte Unsinn einer DLL-Nutzung!). Wenn dann bitte die DLLs auch in einem Zielordner ablegen, wo jedes Programm einen Nutzen davon hat....
Prinzipiell stimme ich Dir zu, aber damit schaffst Du natürlich auch eine Kopplung, die Dir zu schaffen machen kann. Du musst nämlich höllisch auf Kompatibilität der verschiedenen Versionen aufpassen....
Das ist tw. in der Unixwelt dadurch gelöst, dass man in die Namen der "DLLs" die Versionen aufnimmt und das entsprechend konfigurieren kann, aber wenn (wie allermeistens umgesetzt) immer ein fester Name gesucht wird, wird's schnell haarig.
Das ist bisweilen ein Grund, warum ich lieber libs verwende ... da habe ich im Ergebnis auch nur den Speicherplatz der Funktionen, die ich wirklich brauche (und nicht alle - wie bei der DLL), die zwar bisweilen mehrfach im Speicher, aber auch keine Kompatibilitätskonflikte.Langer Rede kurzer Sinn: DLLs sind auch kein Allheilmittel, sondern wollen mit Bedacht eingesetzt werden.
Gruß,
Simon2.
-
Naja, DLL-Versionierung gibts ja zum Glück seit WinXP auch schon. Deshalb braucht man ja die Manifestdatei, wo man die DLL-Version der C-Runtime usw. einträgt. Vorausgesetzt, die DLLs sind versioniert (unversionierte DLLs lassen sich natürlich weiterhin nutzen, und dann tritt das von dir genannte Problem auf).
Muß aber zugeben, das ich mich ansonst mit den versionierten DLLs unter WinXP nicht weiter beschäftigt habe, weil ich selber keine DLLs erstelle (immer nur LIBs).
-
da habe ich im Ergebnis auch nur den Speicherplatz der Funktionen, die ich wirklich brauche (und nicht alle - wie bei der DLL), die zwar bisweilen mehrfach im Speicher, aber auch keine Kompatibilitätskonflikte.
Stimmt! Im optimalen Fall, ist der Linker so schlau, und linkt nur die Funktionen/Klassen, die ich auch aus der LIB verwende. Kann man beim MSVC auch beobachten, das meistens die EXE extrem kleiner ist, als die LIB.
Ja, ist schon ne schwierige Entscheidung.
-
hmm und wie werde ich mir letztendlich beweusst, wann ich eine DLL benutze und nicht eine header???
Gruß Tobi.
-
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Hallo
Der Aufwand eine DLL anzulegen ist wesentlich größer als eine Headerdatei (wie gesagt Übersetzungseinheit ist ein treffenderer Begriff).
Für eine DLL muß im allgemeinen ein neues Projekt/Makefile angelegt werden, so das es völlig unabhängig vom Projekt/Makefile des benutzenden Programmes ist.bis bald
akari
-
hmm, also ich schluss folgere daraus mal das DLL's eigentlich total fürn garten ist oder wie?, und ich mir eigentlich keinerlei mühe machen müsste mir jemals eine dLL zu baun, wenns nen header genauso tut....
Gruß Tobi.
-
Hallo
Es wurden genug Beispiele genannt die DLLs notwendig machen.
bis bald
akari
-
Übrigens können Windows-DLLs mit C++-Code schnell zu Problemen führen, vor allem wenn man auch noch zwei verschieden Compiler oder Compiler-Versionen benutzt. Für Windows gibt es keine definierte C++-ABI, jeder Compiler bzw Compiler-Version macht da was eigenes. Dann gibt es wohl auch Probleme mit Exceptions und Speicher-Verwaltung über Programm/DLL-Grenzen.