Speicherbereich der DLL
-
Dieses Thema gab es bestimmt schon öfters allerdings kommt bei der Suche bei mir immer nur das "test: 2452816-191049-F923"
Mapping von Globalen Variablen und der eigene Speicherbereich sind zwar schon Vorteile, aber im Moment sind sie eigentlich nur Störend.
Gibt es eine Möglichkeit wie man den Speicherbereich zusammen legen kann? So das wenn meine Basis DLL "r3d.dll" nur einmal im Speicher liegt, sammt dem dazugehörigen Speicher?
Für ein bessere Verständnis. Die DLL r3d.dll wird auch von den PlugIn's benutzt. Was bedeutet das mit jedem PlugIn ein eigner Speicherbereich für die r3d.dll angelegt wird
und genau das soll Windows nicht.
-
Wass genau willst du jetzt? Suchst du sowas:
#pragma data_seg ("shared") bool g_bla = false; #pragma data_seg () #pragma comment(linker,"/SECTION:shared,RWS")
-
Was macht dein Beispiel?
Vieleicht so. Ich habe ein Projekt das mit PlugIn's Arbeitet. Die PlugIns's habe ich mittels DLL's realisiert. Der Manager des Projekts ist in der DLL "r3d.dll" Implementiert. Wenn ich nun durch den Manager ein PlugIn lade und dieses PlugIn mit der DLL r3d.dll verlinkt ist, wird ein zusätzlicher Speicherbereich für die r3d.dll erzeugt. Das will ich verhindern oder umgehen.
Der Manager ist als Singleton Konzipiert, wie auch einiege seiner Sub Systeme.[ Dieser Beitrag wurde am 25.06.2003 um 20:02 Uhr von DragonMaster editiert. ]
-
Sorry, dann hatte ich dich falsch verstanden
Die dll wird aber imho nicht nochmal physisch neu geladen, sondern nur in den Adressraum gemappt. Und wenn du das nicht willst, frage ich mich, wozu du sie dann mit r3d.dll verlinkt hast
-
Na wenn ich sie nicht verlinke kann ich ja keine Methoden aus der DLL r3d.dll verwenden. Ein Beispiel. Ich hab in meinem Basis Interface die Methode QueryInterface Implementiert. Diese Methode ruft Manager::QueryInterface auf, das dann ein Interface besorgt. Ein anderes Beispiel. Meine Fehlerklasse ruft z.B. Manager::SetError() auf und ich möchte die Fehlerklasse ja nun auch in meinen PlugIn's verwenden.
Die Handles von z.B. meinem LogSystem rufen z.B. LogSystem::PrintLog auf.Das funktioniert an sich auch sehr gut da der Manager und das Log System als Singleton Konzipert sind. Nur in den PlugIn's scheitert das ganze, da dort durch den Seperaten Speicherbereich keine Instance des Manager und des LogSystems vorliegen.
Ich muss also ermöglichen das die Varialben die die Instance der beiden System speichern auch von den PlugIn's verwendet werden kann.
-
Dann brauchst du vielleicht doch das von oben. Damit kannst du dann in diesem Bereich (Variablen müssen hier gleich initialisert werden) Variablen ablegen, die gemeinsam verwendet werden, also wenn du die DLL z.B. zweimal irgendwo einbindest hast du nur einmal die Variablen
-
Danke. Aber ich hab das Problem jetzt ein wenig anders gelöst. Mein Singleton Design hat diese Probleme verursacht. Wie es scheint sind "static" Variablen in Klassen nicht von diesem Problem betroffen.
Auf jeden fall Klappt jetzt alles. Aber deinen Vorschlag werd ich mir auf jedenfall Merken. Kann ja nie schaden
