Soviel wie möglich in dll umsetzen
-
Nach meiner Meinung gibt es nur ein paar Gründe, DLL's einzusetzen:
1. Mehrere Programme (EXE) brauchen den gleichen Code, wofür die DLL's ja auch gedacht sind.
2. Das Programm wird verdammt groß, sodass der Code nur dann geladen werden soll, wenn er wirklich gebraucht wird.
3. Ich möchte über den Austausch von DLL's das Programm einfacher auf Kundenbedürfnisse anpassen können (Design, Texte, was auch immer). Es reicht dann der Austausch der DLL ohne die EXE ändern zu müssen.Ansonsten fällt mir eigentlich nix ein.
Nachteilig ist, dass Funktionsaufrufe in eine DLL immer einen gewissen Overhead brauchen, was aber in aller Regel nicht spürbar ist. Es sein denn, man übertreibt es. So setzen wir hier einen Designer ein, bei welchem jeder "Furz" in einer eigenen DLL abgelegt ist, obwohl JEDE DLL bei Programmstart angezogen wird. Da kommt man auf 115 DLL's und da knirscht selbst der VC beim Kompilieren. Die Ressourcen-Verschwendung ist ebenfalls grandios.
-
4. wenn man ein updater dabeihat, muss man nur ne neue DLL (wenn vorhanden) laden und nicht das ganze paket
-
Besserwisser sagt: Sofern man die DLL's auch immer schön entladen hat.
Mit dem Problem habe ich mich (unter Anderem) jetzt fast eine Woche herumgeschlagen.
-
Hallo, Manfred Schmidtke schreibt dass mam mit dll's overhead braucht. Was ist damit genau gemeint. Ist das nicht besser so gut wie jede Form in eine dll zu schreiben. Dann wird die Form nur dann geladen wenn diese auch gebraucht wird. Man muß nicht sofort die 50MB laden sonder nur einen bruchteil und den rest wenn man ihn braucht. Ist denn das laden einer dll wirklich so bemerkbar dass man lieber diese in eine exe schreiben sollte?
-
Dieser Thread wurde von Moderator/in Jansen aus dem Forum Borland C++ Builder (VCL/CLX) 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.
-
Ich habe auch geschrieben, das man in der Regel nix davon merkt. Bei der Entwicklung des angesprochenen Designers hat man ALLES in einzelne DLL's gepackt, selbst wenn der Code nur aus fünf Zeilen bestand!
Bei richtig dicken Programmen kommst Du um dynamische DLL's nicht herum. Ob 50 MB schon richtig dick sind, ist eine andere Frage.
Will man ausschließlich dynamisch auf Funktionen einer DLL zugreifen, sieht das z. B. so aus:
void II_OSLib::sendMail (SMTPData& data) { //Library laden OSHANDLE hdll = loadLibrary ( "iismtp.dll" ) ; if ( hdll ) { LPCFSSENDMAIL funcSendMail = (LPCFSSENDMAIL)getProcAdress(hdll,"CFSSendMail"); if ( funcSendMail ) { funcSendMail (data); } unloadLibrary (hdll); return; } strcpy ((char*) &data.msg[0], "Fehler bei Aufruf von SendMail aufgetreten!"); return; }
Hier wird z. B. eine Mail-Funktion aufgerufen. Die DLL wird nur dann geladen, wenn eine Mail versendet werden soll und anschließend wieder entladen. Wäre die Funktion für den Mail-Versand direkt in der EXE, ginge dies mit Sicherheit einige Millisekunden schneller, da der Aufruf der Funktion funcSendMail reichen würde.
Wird die DLL statisch gelinkt, merkt man davon als Programmierer nicht ganz so viel, aber der Vorteil der Speicherersparnis ist auch erst einmal weg (da alle DLL gleich zugeladen werden).
-
Wird die DLL statisch gelinkt, merkt man davon als Programmierer nicht ganz so viel, aber der Vorteil der Speicherersparnis ist auch erst einmal weg (da alle DLL gleich zugeladen werden).
/DELAYLOAD und /DELAY sind Workarounds bei solch einem Problem.
-
Ein Bsp. von vielen DLL ist PDF-Reader (Adobe).
Das laden braucht sehr lange da viele DLL (Plugins) geladen werden müssen.Grundsätzlich kommt es immer auf die Art des Programmes an.
GUI und Funktinen sollen sowieso immer getrennt werden.
Will man eine PluginSchnittstelle für die GUI kommt man auch hier um DLL nicht herum (außer man macht das mit Scripts oder ähnlichem.)Wenn ich Mail, etc. einem Programm habe verwende ich auch DLL da ich die SMTP, Filefunktionen, Datenbank, etc. in DLL`s ausgelagert habe und beim Programm dann nur die Header einbinden muss.
Diese Funktionen sind in meinen Programmen immer gleich. Änderungen am Code braucht dann nur DLL-Austausch.
-
Manfred Schmidtke schrieb:
Nachteilig ist, dass Funktionsaufrufe in eine DLL immer einen gewissen Overhead brauchen
welchen overhead?
-
rapso schrieb:
Manfred Schmidtke schrieb:
Nachteilig ist, dass Funktionsaufrufe in eine DLL immer einen gewissen Overhead brauchen
welchen overhead?
Naja, die Adresse sollte ja eigentlich unabhängig sein, muss also vom Offset her neu berechnet werden. Unter Windows gibt es aber afaik die Unsitte, dass die meisten DLLs an eine feste Adresse gemappt werden. Bin mir da aber nicht so genau sicher.