Gerade gelesen.
Zitat:
Ein Objekt in einer
DLL zu instantiieren ist problemlos. Man muss es halt nur explizit machen.
Probleme treten erst auf wenn man das Objekt an das Hauptprogramm gibt.
DLL und Hauptprogramm haben separate Memorypools. Die Einbindung von ShareMem beseitigt diese Probleme.
Aber trotzdem sitze ich hier, habe kein ShareMem eingebunden und mein Hauptprogramm gibt mir anstandslos die in der
DLL erzeugte Stringliste aus.
Ich lass mir das testweise in einer Messagebox ausgeben
Delphi-Quellcode:
teststring:=commands('test');
showmessage(teststring[0]+' '+teststring[1]+' '+teststring[2]);
Funktioniert.
So lange
DLL und Anwendung durch den gleichen Compiler erzeugt wurden, kann das funktionieren.
Die Methode Destroy ist "virtual" und wird somit über die Klassenreferenz des Objektes in der
DLL aufgerufen.
Aber schon der Vergleich "(teststring is TStringList)" dürfte in der Anwendung "False" ergeben.
Der Stringliste dürfen auch nur einzelne String-Konstanten hinzufügt werden.
Für diese wird keine Referenzzählung und keine automatische Freigabe durchgeführt.
Wird ein String in der
DLL mit dem Speichermanager der
DLL erzeugt, wird bei der Freigabe unter Umständen der Speichermanager der Anwendung aufgerufen, der für diesen Speicherbereich nicht zuständig ist.
Gefährlich wäre z.B.:
Delphi-Quellcode:
{in der DLL:}
Liste.Add('
function' + IntToStr(i));
{in der Anwendung mit der selben Liste:}
s := teststring[0];
teststring.Free;
s := '
';
// <- Hier könnte es dann einen Fehler geben, da Referenzzähler des Strings auf 0 fällt