2009-06-17 7 views
1

Ich bin mir ziemlich sicher, dass dieses Problem nicht neu ist, und ziemlich sicher, dass es schwer zu lösen ist. Hoffentlich liege ich falsch bei letzterem.Loki Singleton zum Arbeiten in DLLs in VS 2008 C++

Ich versuche, das Loki :: Singleton von Modern C++ Design in einem Programm von mir zu verwenden.

Allerdings kann ich nicht scheinen, es über DLLs zu arbeiten. Ich denke, ich weiß, warum dies geschieht: Der Vorlagencode wird in jedem Quellmodul instanziiert, sodass anstelle einer einzigen globalen Variablen jedes Modul seine eigene hat.

Offensichtlich macht dies das Singleton sehr viel nicht-Single.

Gibt es eine Möglichkeit, dieses Verhalten zu umgehen?

Antwort

2

Ich sehe im Loki Quellverzeichnis, dass sie eine spezifische SingletonDLL directory im Test haben, sieht aus wie sie eine exportierte, explizit instanziierte Vorlage verwenden (was funktionieren würde). Hoffentlich enthält das den Code, den Sie möchten.

+0

Danke, Todd !. Das schien zu funktionieren, und ich fand diesen [KB Artikel] (http://support.microsoft.com/kb/168958) der ausführlich erklärt, was der Beispielcode von SingletonDll (in Loki) macht.Es ist ein Schmerz, richtig zu funktionieren (mit allen declspecs und so), und es lässt mich immer noch mit Code wie m_tick_file = Tick_File_Factory :: Instance() .CreateObject ("OHLC_File")); in meinen Apps. Ich denke, ich könnte am Ende statische Memberfunktionen zu Tick_File hinzufügen, die intern das Loki-Zeug verwenden, dann weiß ich, dass die Vorlagen nur einmal in der .cpp für Tick_File installiert werden –

0

Sie haben wahrscheinlich richtig, dass jede DLL eine eigene Instanz des Singleton hat. Ich bin nicht so vertraut mit der Loki-Implementierung und die source code macht nicht viel Spaß, um herauszufinden.

Mögliche Lösungen sind:

  • Nicht Singletons verwenden. Dies ist eigentlich meine übliche Vorliebe, da Sie ganze Klassen von Problemen vermeiden können, indem Sie Ihr Design ändern, um sie nicht zu benötigen. Für eine lange Debatte darüber, warum Singletons schädlich sein können, siehe this Yegge Post. Ich bin nicht so heftig gegen sie, aber 95% der Zeit Singletons verursachen viel mehr Probleme als sie lösen (wenn sie tatsächlich lösen)
  • Kopieren von statischen Mitgliedern über DLL-Grenzen. Ich habe das auch als Hack gemacht, wo die DLL einen Zeiger von einer Anwendung oder einer anderen DLL erhält und ihre eigene Kopie des statischen Klassenmembers auf den von außen übergebenen Zeiger zurücksetzt. Es ist böse, es ist schmutzig, du kannst es danach nicht aufräumen, aber es funktioniert.
+0

Wenn Sie downvote, bitte Kommentar auch warum. –

1

Beachten Sie, dass dies die Frage nicht beantworten wird. Eine explizit instanziiert und exportiert Singletons sollte es tun ...

-Rick

Check out Pragma data_seg here im Grunde, müssen Sie eine Instanz des Singleton in einem gemeinsamen Abschnitt des Codes erklären. Standardmäßig sind Statiken auf die DLL beschränkt.

Es kann schwierig werden, mit Vorlagen, aber das ist der Weg zum Erfolg hier, die keine Weitergabe/Kopieren von statischen Daten um.

+0

Ich habe heute etwas Neues gelernt. Vielen Dank! –

+1

Das scheint nicht zu tun, was ich will. Mit dem #pragma data_seg kann ich Daten zwischen PROGRAMMEN teilen. Das Problem, das ich habe, ist, zwischen DLLs zu teilen. Die Einschränkungen auf der Seite, auf die Sie verwiesen haben, geben explizit an: "Jeder Prozess erhält seinen eigenen Adressraum. Es ist sehr wichtig, dass Zeiger niemals in einer Variablen in einem freigegebenen Datensegment gespeichert werden eine Anwendung, aber nicht in einer anderen. " Und der Singleton verwendet interne Zeiger. –

+0

Sie sind richtig, sorry. Todds Antwort ist korrekt. – Rick