Singleton über DLL Grenzen verwenden

Reply to Singleton über DLL Grenzen verwenden on Mon, 10 Sep 2007 17:49:09 GMT

JimmydaMage — Mon, 10 Sep 2007 17:49:09 GMT

Hallo,

ich bin gerade dabei, eine Singleton Logger-Klasse für mein Programm zu schreiben...
Dabei würde ich gerne ein automatisches Exception Logging implementieren, so dass
jede Exception einen Eintrag in der Log-Datei hinterlässt.
Jetzt hab ich aber das Problem, dass Teile meines Programms in Plugin-DLLs ausgelagert sind. Das Werfen von Exceptions von dort ins Hauptprogramm funktioniert auch anstandslos, nur hab ich ja dann das Problem, dass ein Zugriff von innerhalb einer DLL auf ein Singletonobjekt eine zweite Instanz erzeugen würde...
Kann mir jemand Vorschläge nennen, wie ich um das Problem möglichst sauber herumarbeiten kann?

Grüße,

Martin

Reply to Singleton über DLL Grenzen verwenden on Mon, 10 Sep 2007 18:45:47 GMT

*D*Evil — Mon, 10 Sep 2007 18:45:47 GMT

Referenz auf den Singleton beim Initialisieren der DLL übergeben ...

Reply to Singleton über DLL Grenzen verwenden on Mon, 10 Sep 2007 22:40:10 GMT

hustbaer — Mon, 10 Sep 2007 22:40:10 GMT

Wo erzeugt was warum eine 2. Instanz?

Wenn die Logger-DLL z.B. eine GetLogger() Funktion hat, welche eine Referenz auf das Singleton zurückliefert, dann funktioniert das. Innerhalb eines Prozesses hast du dann immer nur eine Instanz des Singletons - vorausgesetzt dein Singleton funktioniert.

Verstehe das Problem nicht...

p.S.: falls der "Logger" noch nicht in seiner eigenen DLL lebt, dann lager den einfach in eine DLL aus. Dann kannst du das Hauptprogramm und die anderen DLLs gegen die Logger-DLL linken, und alles sollte gut sein.

Reply to Singleton über DLL Grenzen verwenden on Tue, 11 Sep 2007 07:22:22 GMT

DeSoVoDaMu — Tue, 11 Sep 2007 07:22:22 GMT

Hi,
ein bisschen OT aber sollte man nicht dafür Sorge tragen, dass Exceptions nicht die DLL verlassen?

Gruss,
DeSoVoDaMu

Reply to Singleton über DLL Grenzen verwenden on Tue, 11 Sep 2007 07:42:10 GMT

ghorst — Tue, 11 Sep 2007 07:42:10 GMT

die antwort ist: ja und nein.
ja, weil man damit richtig spaß beim casten bekommen kann.
nein, weil es ein sehr wichtiges hilfsmittel zur fehlerbehandlung ist.

in den meisten fällen, also immer wenn du nicht über dll-grenzen hinweg klassenhierachien aufbaust, was bei exceptions nun wahrlich recht ungewöhnlich ist, gibt es keinerlei probleme, daher kann man recht sorgenfrei exceptions über dll-grenzen hinweg werfen.

falls du interne exceptions meinst, so ist antwort definitv ja. man sollte die internen fehler in sinnvolle, eigene exceptions verpacken.

Reply to Singleton über DLL Grenzen verwenden on Tue, 11 Sep 2007 12:37:07 GMT

JimmydaMage — Tue, 11 Sep 2007 12:37:07 GMT

Meine Programmstruktur ist leider etwas komplizierter...
Das ganze soll eine rudimentäre 3D-Engine werden.
Die eigentliche Engine-Funktionalität liegt momentan in einer statischen Bibliothek (soll später eine DLL werden). Beim Laden lädt die Engine eine Plugin-DLL, die eine Funktion "CreateInstance" exportiert, die ein abgeleitetes Objekt einer virtuellen Renderer-Basisklasse zurückgibt. Wenn also der Renderer einen Fehler feststellt, wird eine Exception zurück an die Engine geworfen, was, wie gesagt, auch funktioniert. Da der Renderer aber ja Zugriff auf die Mehoden der Engine-Objekte benötigt, muss ich die Plugin-DLL auch gegen die Engine-Bibliothek linken (ich hab irgendwie den Eindruck, dass ich irgendwann damit höllisch auf die Schnauze flieg ).
Der Logger ist ein Objekt der Engine, aber der Renderer weiß ja nicht, dass die Engine selbst eine Instanz davon erzeugt, folglich würde der Renderer beim ersten Zugriff auf den Logger eine neue Instanz erzeugen, *Bumm*.
Ich hab mich vorerst entschlossen, dem Logger eine "InjectInstance" Methode mitzugeben, die einen Zeiger auf den Instanzzeiger des orginalen Loggerobjekts erwartet, so dass die Klasse auch mit einem fremden Instanzzeiger arbeiten kann. Nur so kann ich gewährleisten, dass beide Module tatsächlich mit dem selben Objekt arbeiten...

Grüße,

Martin

Reply to Singleton über DLL Grenzen verwenden on Wed, 12 Sep 2007 00:38:22 GMT

hustbaer — Wed, 12 Sep 2007 00:38:22 GMT

Äh.
Vorschlag: pack gleich alles in DLLs. Dann hast du jetzt das was du sowieso schon machen willst, und kein Problem mehr mit dem Logger. Verwende für alle DLLs und Programme den selben Compiler und überall die selbe Runtime DLL, und fertig.

Den Logger würde ich einfach als Singleton in der DLL beheimaten die den Logger implementiert. Dann kannst du jederzeit überall das Singleton verwenden indem die die Funktion der Logger-DLL verwendest eine Referenz darauf zu bekommen, und es wird immer der selbe Logger sein, egal wo du ihn anforderst.

Mit MSVC zumindest kannst du auch Exceptions wie du willst werfen und fangen, DLL Grenzen spielen dabei keine Rolle. Dasselbe gilt für RTTI und dynamische Speicherverwaltung. (Vorausgesetzt natürlich: gleiche MSVC Version, gleiche Runtime DLL - siehe oben)

Worüber man sich natürlich im Klaren sein muss ist dass gewisse Dinge beim Linken nichtmehr zusammengeführt werden wenn man LIBs gegen DLLs tauscht, wie z.B. statische Variablen bzw. "class-statics" in inline Code. Unter Linux funktioniert das AFAIK, unter Windows i.A. nicht (kann sein irgendein Compiler implementiert es, wäre mir aber nix bekannt, und sicher nicht MSVC).

Reply to Singleton über DLL Grenzen verwenden on Wed, 12 Sep 2007 17:20:40 GMT

JimmydaMage — Wed, 12 Sep 2007 17:20:40 GMT

Jo, danke, das funktioniert jetzt anstandslos.
Aber kann ich mich auch darauf verlassen, dass statische Member von Klassen, die in einer DLL liegen immer an der gleichen Adresse liegen, wenn die DLL von zwei verschiedenen Modulen unabhängig eingebunden wird?

Danke,

Martin

Reply to Singleton über DLL Grenzen verwenden on Wed, 12 Sep 2007 17:28:40 GMT

hustbaer — Wed, 12 Sep 2007 17:28:40 GMT

Wenn diese statischen Member nicht in inline Code definiert werden (der in anderen Modulen expandiert werden könnte), dann kannst du dir sicher sein dass sämtliche "Module" (DLLs) in einem Prozess die gleiche Adresse sehen werden, ja.
Genauso wie ja auch die Adresse von Funktionen in DLLs für alle anderen DLLs gleichist.

Für unterschiedliche Prozesse gilt das natürlich nicht unbedingt.