C++ Klassen in DLL

Hallo !

Kurze Frage, kann man C++ Klassen in DLL's auslagern, so das man nur die Headerdatei includieren muss, und man dann einfach new Klasse erzeugen kann ?

Und wenn ja, wie realisiert man es, wenn man diese Klassen die in DLL's ausgelagert sind, vererben will?? Soviel ich weiß muss man ja Methoden einer Klasse, von der man vor hat sie zu vererben, mit dem Modifier virtual versehen.

Ich würde mir gerne Wrapperklassen für die WinApi machen, und diese gerne in DLL's auslagern.

Danke schon mal im Voraus.

simon.gysi

Ich würde nur über Interfaces und Basistypen über DLL Grenzen hinweg kommunizieren. D.h. also keine Klassen exportieren.

Schaue Dir mal die MSDN Doku zu dllexport, dllimport und *.def Files an.
Simon

Dachte schon dass das keine gute Idee ist, da ja C++ DLL's nur mit dem gleichen Compiler verwendet werden sollten.

Ich schau mal in der Doku, falls noch jemand Tipps hat wie man das am besten realisiert, bitte melden

jd

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?

Ich kenne mich mit DLL's (mit C++) nicht wirklich aus, deswegen kann ich dir nicht viel mehr sagen, außer das ich gelesen habe, dass C++ DLL's nur mit dem Compiler verwendet werden sollten, mit welchem sie auch erstellt wurden, ob das stimmt oder nícht weiß ich nicht (würde mich auch interessieren).

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.