C++ Klassen in DLL

jd

Also das kann ich nicht bestätigen. Meine DLLs werden mit MinGW erstellt, laufen dann aber auch mit VS-Compiler. Wäre ja irgendwie Käse wenn das nicht gehen würde. Ich meine du kannst ja nicht riechen mit was die DLL kompiliert wurde, von daher würde ich jetzt mal sagen das es da allgemein keine Probleme gibt, bzw ich hatte noch nie eins.

RHBaum

Es ist "gefaehrlich" ^^ zumindest unter windows.

Klar kann man es machen, wenn man beide seiten, also die exe und die dll unter controlle hat. MS bietet sowas ja an, MFC erweiterungs Dlls etc.

Wo man ganz schnell davon weggehen sollt, ist wenn exe und dlls auf unterschiedliche Programmierer,Abteilungen, oder gar Firmen aufgeteilt werden. weil wie oben erwaeht, nur bei C die Symbole 100% definiert sind.
C++ Symbole, also klassenmethoden etc, werden zwar auf C Symbolen abgebildet, aber die Hersteller haben volle freiheit wie sie die namen generieren (name mergling) und die parameter ausrichten.
Da gibts leider noch kein standard.

Prominentes beispiel, ist zum beispiel die QT ...
die exportiert c++ symbole ueber ihre DLLs. will man den compiler, oder die version wechseln, muss man sich ne komplett neue Umgebung schaffen, also meist die komplette QT neu compilieren.
Zentrale ablage der QT dlls nimmer moeglich ... Also muessen die dlls immer mit dem programm installiert werden, und der User hat tonnenweisse dlls aufn rechner ^^ Mit der QT3 haben wir deswegen schon viel spass gehabt, da haben sich die QT dlls ins system eingeklingt (system32) und damit andere versionen ueberschreiben. Man wunderte sich dann, warum ploetzlich andere programme nimmer laufen

Warum eher windows als nen Linux Problem ?
Unter linux gibts nen systemcompiler (gcc meist). wenn der ausgetauscht, wird eh alles neu installiert. und die meist nachtraeglich installierte software kommt als code und wird auf dem zielrechner installiert. da passt meist immer alles.

unter windwos isses ned so, da wird kaum code verteilt, sondern immer nur binaeries, da keiner weiss was fuer compiler die nehmen, sollte man als schnittstelle zu anderen programmen das groestmogliche gemeinsame nehmen, und das ist bei DLLs nun mal C ....

Ciao ...

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.