C++ Klassen in DLL

RHBaum

Meine DLLs werden mit MinGW erstellt, laufen dann aber auch mit VS-Compiler

Definitiv nicht ! sicher das da C++ Elemente im spiel sind (Klassen) ?
Hier bei uns, klappt es schon mit normalen funktionen zwischen gcc(mingw) und VS 2005 ned, wenn die ned als "extern C" gekennzeichnet sind.

Ciao ...

jd

Tatsache... das geht wirklich nicht war mir sicher das dass geht... das ist ja mal doof. Sprich wenn ich mit gcc eine DLL mache, muss der, der mit der DLL arbeiten will, auch gcc verwenden... das ist ja doof.

simon.gysi

jd schrieb:

Da komme ich jetzt nicht ganz mit. Warum sollte man keine Klassen in eine DLL schieben?

Ich habe in mein Programm ein Network "Modul" eingebaut.
class CNetwork 
{
public:
  CNetwork();
  ~CNetwork();
/* usw */
};

class CHttp : public CNetwork
{
/* usw. */
};
Warum ist das falsch komplexe Sachen in eine DLL aus zu lagern? Oder verstehe ich da was falsch?

Ja, definitiv falsch verstanden.
Auslagern wenn nötig ist ok. Jedoch Interface und Impl. gut trennen (via Bridge Pattern): Interface (nur pure virtual funtktionen) machen und factory zur verfügung stellen (via eine exportierte (C) Funktion).

In den Interfaces dann nur Basistypen verwenden, so werden die Abhängigkeiten von konkreten impl. vermieden.

So macht das übrigens COM.

Simon

jd

Wie sieht denn eine exportiere (C) Funktion aus?

Also mal allgemein betrachtet, sollte man eine DLL oder generell eine Bibliothek immer nach dem Bridge Pattern machen?

simon.gysi

Ich finde das einen guten Ansatz.
Hat sich bewährt.

asc

simon.gysi schrieb:

Auslagern wenn nötig ist ok. Jedoch Interface und Impl. gut trennen (via Bridge Pattern): Interface (nur pure virtual funtktionen) machen und factory zur verfügung stellen (via eine exportierte (C) Funktion).

In den Interfaces dann nur Basistypen verwenden, so werden die Abhängigkeiten von konkreten impl. vermieden.

Wie sieht es eigentlich in einer homogenen C++ Umgebung aus (Sowohl die Exe als auch die DLL's in eigener Hand und bei einem gleichen Compiler)? Ich habe mich selbst schon mit den Ansatz der rein virtuellen Funktionen (inkl. Basisdatentypen) beschäftigt, aber mich interessiert ob es in einer homogenen Umgebung auch mit komplexeren Typen geht?

Zudem würde mich interessieren wie die Freigabestrategie aussieht. Bei den damaligen Recherchen (binärkompatible C++ Interfaces) bin ich auch auf eine operatorüberladung (delete) zu der Klasse gestoßen (Als inline-Methode im Interface, das wiederum auf eine virtelle Destroymethode zurückgreift). Ist dies ein sauber gangbarer Weg (oder wiederspricht es dem Gedanken der rein virtuellen Schnittstelle, da die Operatorüberladung ja nicht virtuell ist).

cu André

Wie sieht es eigentlich in einer homogenen C++ Umgebung aus (Sowohl die Exe als auch die DLL's in eigener Hand und bei einem gleichen Compiler)?

Das funktioniert einwandfrei. So mache ich es jetzt schon eine ganze Weile (verwende ueberall visual studio 2008) und habe noch keine Probleme gehabt (exportiere komplexe Klassen und importiere sie dann wieder im eigentlichen Programm).

Ich bezweifele auch, dass ich jemals auf Interfaces und Factories zurueckgreifen werden, da mir das sehr viel Aufwand erscheint.

LordJaxom

asc schrieb:

Wie sieht es eigentlich in einer homogenen C++ Umgebung aus (Sowohl die Exe als auch die DLL's in eigener Hand und bei einem gleichen Compiler)? Ich habe mich selbst schon mit den Ansatz der rein virtuellen Funktionen (inkl. Basisdatentypen) beschäftigt, aber mich interessiert ob es in einer homogenen Umgebung auch mit komplexeren Typen geht?

Machen wx, QT, Boost und viele andere seit Jahren

Bashar

Mal rein interessehalber, gibt es außer der Binärkompatibilität noch was zu beachten, wenn man C++ mit DLLs zusammenbringt? Wie sieht es mit Initialisierung und Aufräumen von statischen Objekten aus? Einschränkungen beim Speichermanagement oder bei Exceptions?

asc

Bashar schrieb:

...Einschränkungen beim Speichermanagement oder bei Exceptions?

Das ist ein guter Punkt. Exceptions über DLL-Grenzen in einer homogenen Umgebung, weil außerhalb einer homogenen Umgebung gilt ja die Regel: Niemals Exceptions über DLL-Grenzen werfen.

Mojo.Zache

asc schrieb:

Niemals Exceptions über DLL-Grenzen werfen.

warum eigentlich nicht?

asc schrieb:

Bashar schrieb:

...Einschränkungen beim Speichermanagement oder bei Exceptions?

Das ist ein guter Punkt. Exceptions über DLL-Grenzen in einer homogenen Umgebung, weil außerhalb einer homogenen Umgebung gilt ja die Regel: Niemals Exceptions über DLL-Grenzen werfen.

Exceptions kann man in einer homogenen Umgebung werfen und fangen. So zumindest bei mir, auch wenn ich das ganze nicht exzessiv betreibe..

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.

asc

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).

Bashar

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.

asc

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ß.