Speicher anfordern nur über DLL
-
Hallo,
ich möchte in meinem Projekt DLL's einsetzen. Einmal um code auszulagern, aber auch für plugins. Nun kann man ja nicht new in einer DLl aufrufen und in der exe oder in einer anderen DLL wieder freigeben. Also hab ich mir gedacht, ich schreibe eine DLL, in der der Speicher angefordert wird. Diese DLL enthält einene Singleton Klasse und 2 export funktionen ala New() und Free(), über die der Speicher angefordert wird. Die DLL binden wiederum alle exe und dll's ein. Meine Versuche haben ergeben das alle auf die gleiche Singleton Klasse zugreifen. Hab also einen "globalen einheitlichen Speicherstandort".
Nun die Frage: Ist das ein guter ansatz oder eher schlecht?
Was gäbe es noch für Möglichkeiten. Wie machen das große Hersteller die Pluginmöglichkeiten haben und auch Speicher in DLL anfordern. Besitzen die auch einen MemoryManager in einer DLL?
-
-
1. Wenn Du ein geschlossenes System hast, in dem die gleiche CRT als DLL genutzt wird und sowohl EXE als auch DLL vom selben Compiler genutzt werden kannst Du ohne Gefahr new und delete verwenden.
2. Ist eine der Bedingungen oben nicht gegeben (Gleicher CoOmpiler, gleiche CRT als DLL), dann musst Du zum Factory oder Interface Ansatz greifen.BTW: Ich finde Deine Anfrage verwirrend, denn bei "Globalem Speicher in DLLs", wie Du es hier schilderst, denke ich schnell auch an Memory Mapped Files und Shared Memory...
-
War blöd ausgedrückt, ich weiß. Es geht nicht darum Speicher zwischen Prozessen auszutauschen (wie schon erkannt).
Das man die gleiche CRT/ und Compiler verwenden kann/muß mit new/delete weiß ich ja schon. Kann man aber bei einem Plugin nicht garantieren =). Daher das auslagern des MemoryManagers. Wenn ich es schon über ein Interface mache, könnte man doch auch gleich so eine Art Garbage Collector basteln, oder?
Kann man den new/delete auch irgendiw exportieren wenn es chon ein Interface sein soll?
-
Kann man den new/delete auch irgendiw exportieren wenn es chon ein Interface sein soll?
Das wird üblichweise in eine Factory (Methode) gepackt.
Zurückgegeben wird ein Interface (abstrakt).Siehe mein vorheriger Post.
Simon
-
Wenn du mit reinen Interfaces arbeitest, dann brauchst du kein zentrales new/delete.
Du musst dann nur sicherstellen dass alles dort freigegeben wird wo es angefordert wurde, und das geht z.B. mit intrusive-reference-counting ganz von selbst.EDIT: natürlich nur wenn der "release" Code niemals irgendwo inline in einem Header vorkommt - sollte logisch sein /EDIT
-
Genau um dieses sicherstellen geht es ganz genau =).
Ich versuche derzeit schon die globalen new und delete funktionen zu überschreiben. Nur mit void delete[](void*) throw() klappt es noch nicht ganz.
-
globale new und delete funktionen zu überschreiben, ist eine ganz schlechte idee.
Dasa würde ich lassen.
zumal irgendwie sichergestellt werden muss, dass deine plugins auch die überschriebenen versionen benutzen, was dazu führt, dass der plugin-code von deinem Code abhängig wird.
-
verwende intrusive reference-counting. ala COM. dann musst du keine new/delete operatoren redefinieren. was mit MSVC sowieso nicht so einfach geht, bzw. unter windows generell nicht compilerübergreifend möglich ist.
