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.

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

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

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?

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

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

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

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

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.

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

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

Niemals Exceptions über DLL-Grenzen werfen.

warum eigentlich nicht?

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

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

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

Welchen Sinn/Vorteil habe ich dann noch mit DLLs?

Plug-ins.

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.

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.

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é