Zitat von
littleDave:
So schlimm ist es nicht, da man vor dem finalization der
DLL (also auch da, wo der Speicher der SysUtils wieder freigegeben wird), die Funktion DLL_ResetMemoryManager aufruft und somit den MemoryManager vom Anfang wieder als aktiv setzt.
Da würde ich an deiner Stelle nicht so einfach und blind drauf vertauen.
z.B. rufe mal die Funktion
Languages aus der
Unit SysUtils auf.
Diese nutzt intern ein Objekt, welches nicht schon in der Initialisierung der
Unit erstellt wird, sondern erst beim ersten Aufruf der Funktion, allerdings wird dieses Objekt erst in der Finalisierung der
Unit freigegeben
und da hast du dem Objekt schon seinen Speichermanager gemopst, in welchem es erstellt wurde.
Und da gibt es noch mehrere Stellen, wo soetwas passiert.
z.B. Application der
Unit Forms ist da auch ein netter Fall
und dann gibt es noch mehr in Classes, Graphics und vorallem die
Indy's sind da nette Gegenspieler
usw.
Also wenn man da in seinem eigenem Programm die Kontrolle darüber behält, was wo und vorallem wann erstellt/freigegeben wird, dann kann man es sich schon einfach machen,
Aber wenn du z.B. sowas wie deine Script-Sprache auch mal an andere Programmierer weitergeben willst, wo du absolut keinen Einfluß auf das Speicherverhalten hast, dann sollte man schon etwas aufpassen.
[add]
PS: Aus diesen Gründen wird bei meiner Version auch (1.) die
DLL dynamisch geladen, damit sich der Speichermanager der EXE noch vor dem der
DLL initialisieren kann.
Und (2.) der Manager innerhalb der
DLL wird noch vor "allen" anderen Units innerhalb der
DLL gestartet/übernommen, also noch von der Initialisierung von z.B. SysUtils und nach derern Finalisierung wird der MM auch erst wieder an das System (die EXE) zurückgegeben.
Und das 2. Verhalten ist auch bei allen Shared-MemoryManagern gleich.
1. ist bei mir nur umgekehrt, da ich ja den MM von der EXE auf die
DLL übertragen möchte.
Möchte man den MM von der
DLL in der EXE nutzen, so wie es sonst alle anderen Shared-MMs machen, dann muß die
DLL statisch vor der EXE geladen werden.