C++ Klassen in DLL
-
Gröhler schrieb:
Der einzige Vorteil den ich sehe, ist das die Build-Zeiten kürzer werden. Aber beim Deploy sehe ich soweit keinen nennenswerten Vorteil mehr.
Wie wäre es den schlicht und ergreifend mit Softwaremodulen die eine Kundenabhängige Implementation benötigen? (Eine DLL mit der Standardlösung, und jeweils eine weitere falls es Kundenspezifisch Abweichungen gibt).
-
Man kann auch statische LIB-Dateien an den Kunden weiter geben. Der linkt diese halt.
Und wenn es ein Kunde ist, der kein Coder ist (weil Endanwender), dann gib ich ihm eh ein fertiges EXE-Packet (der wird dann auch nicht wissen, was er mit ner einzelnen DLL anfangen soll).
-
Gröhler schrieb:
Welchen Sinn/Vorteil habe ich dann noch mit DLLs?
Plug-ins.
-
Gröhler schrieb:
Welchen Sinn/Vorteil habe ich dann noch mit DLLs?
Dann kann ich ja auch gleich statisch linken. Der einzige Vorteil den ich sehe, ist das die Build-Zeiten kürzer werden. Aber beim Deploy sehe ich soweit keinen nennenswerten Vorteil mehr.Du brauchst nur die Dll auszutauschen, wenn darin ein Fehler behoben wurde. Ausserdem kann sie von mehreren Programmen/Dlls geladen werden und belegt nur einmal Speicher.
Irgendwo wuerden hier mal eine Menge Argumente fuer und gegen Dlls genannt, diese treffen ja ansich noch zu, werden nur in ihrer Anwendung etwas eingeschraenkt.
-
outgelogged schrieb:
Du brauchst nur die Dll auszutauschen, wenn darin ein Fehler behoben wurde. Ausserdem kann sie von mehreren Programmen/Dlls geladen werden und belegt nur einmal Speicher.
Schön und gut. Diese Argumente, auch mit den Plugins, sind mir bekannt. Nur finde ich, werden die Argumente nichtig, wenn ich das ganze nur mit einer bestimmten Compiler-Version (teilweise sogar einer CRT-Version!) machen kann.
Generell sind die DLL-Argumente ja schön, solange... na, ihr wisst schon.
-
Gröhler schrieb:
Schön und gut. Diese Argumente, auch mit den Plugins, sind mir bekannt. Nur finde ich, werden die Argumente nichtig, wenn ich das ganze nur mit einer bestimmten Compiler-Version (teilweise sogar einer CRT-Version!) machen kann.
Okay, nehmen wir noch einen weiteren Fall an. Dein Programm arbeitet mit 2 grundverschiedenen Datenbankstrategien die je nach Installationsauswahl aktiv sein sollen (Die eine Transaktionsgestüzt auf Datenbank A, die andere ohne Transaktionen auf Datenbank B. Variante A soll in Zukunft die bevorzugte Variante sein, der Anwender kann sich bei der Installation aber aussuchen ob er mit einer richtigen Datenbank, oder einer Filebasierten Lösung arbeitet).
Wie würdest du das statisch gelinkt lösen? Zudem: Wenn ein Fehler in einer der beiden Varianten vorhanden ist, muss nur dessen Update geladen werden.
cu André
-
Na, sowas löse ich hoffentlich über eine Konfiguration, und zur Laufzeit wird entschieden, welche Strategie instanziert wird. Wenn ich den User bei der Installation festnagel, wird er bei einem späteren Switch ganz schön fluchen.
Zu dem Fehler: das kann man mittels eines Patches lösen, wenn der Download/Installer klein gehalten werden soll und man nicht einfach eine komplette EXE ausliefern will.
Wie gesagt, die DLL-Philosophie finde ich auch toll. Aber ich finde sie leider durch die ABI-Inkompatibilität nicht sehr nützlich, für einen C++'ler. Die Gefahrenquellen und der Aufwand dahinter, ist zu groß. Ich mache zur Zeit alles über statische LIBs und programmiere C++ so, das ich keine Hindernisse zu umgehen habe.
Zumindest innerhalb einer Plattform sollten DLLs funktionieren (oder einer CRT-Version!), dann würde ich sagen: ja, DLLs machen mir keine Sorgen, als C++ler.
Wer natürlich sich die Extra-Arbeit gerne macht, sollte das natürlich so beibehalten. Will ja nicht sagen, das man es nicht machen soll. Aber für mich pers. sind die Fallstricke doch zu groß.