Liebes Forum,
die letzte Zeit ereilten mich diverse madExcept-Mails bzgl. eines offenkundigen Problems mit einer Ini-File-Instanz des Objekts System.TIniFile. Das Interessante daran: laut madExcept Callstack soll das Problem beim
Zerstören der Instanz auftreten. Es hagelt dann so eine wunderbar aussagekräfte Fehlermeldung a la
"
Access violation at address [...] Read of address [...]".
Jetzt habe ich mir mal gedacht, dass ich mir das genauer anschauen muss. Zunächst mal den Code, den ich verwende (stark gekürzt):
Delphi-Quellcode:
iniFile := nil;
try
iniFile := TIniFile.Create(FIniFile);
// ReadBool, ReadString, etc.
finally
if iniFile <> nil then
iniFile.Free;
end;
Gesetzt dem Fall, dass ich nicht wieder was verpasst habe und der Aufruf von
Free tut auch noch immer das, was er soll (den Destructor aufrufen), dann sind an dieser Stelle an sich keine Fehler zu erwarten.
Dennoch sind ja offenbar Zugriffsfehler da, sonst würde madExcept sich ja nicht melden.
Ich hab mir also mal die Klasse
System.TIniFile genauer zu Gemüte geführt. Diese leitet ja von TCustomIniFile ab und die dann wiederum von TObject. Die Klasse
TIniFile besitzt einen eigenen Destruktor, aber keinen eignen Konstruktor. Die (Eltern-)Klasse
TCustomIniFile ist dann das passende Pendant dazu mit einem eigenen Konstruktor aber keinem Destruktor. Mal abgesehen davon, dass alleine das schon verwirrend ist und meiner Meinung nach nicht sauber, wird es noch interessanter, wenn man sich Konstruktor und Destruktor genauer ansieht:
Delphi-Quellcode:
constructor TCustomIniFile.Create(const FileName: string);
begin
FFileName := FileName;
end;
destructor TIniFile.Destroy;
begin
UpdateFile; // flush changes to disk
inherited Destroy;
end;
Meine Frage an der Stelle: wie kann es sein, dass eine Klasse von TObject erbt, aber dessen Konstruktor nicht aufruft? Ich erwarte eigentlich ein
inherited Create. Zudem frage ich mich dann noch, wie es sein kann, dass im Destruktor dann ein
inherited Destroy aufgerufen wird, was meiner Meinung nach den Destruktor desjenigen
TObjects ausführt, das ja offenbar niemals erzeugt wurde.
Und um das jetzt noch weiter abzurunden: Fehler bekomme ich nur, wenn ich das in einer
DLL ausführe! In unseren Executables, die wir seit Jahrzehnten haben und pflegen, ist mir so etwas noch nicht unter gekommen.
Kann mir bitte jemand erklären, wieso diese Objekte überhaupt funktionieren? Die Klasse
TCustomIniFile wird erzeugt, aber ohne explizit den Konstruktor von TObject aufzurufen. Gleichzeitig wird dann aber explizit der Destruktor von
TObject aufgerufen, wenn es daran geht,
TIniFile zu zerstören. Die folgende Frage mag jetzt doof klingen aber ich muss sie stellen: Sind Konstruktoren implizit und Destruktoren nicht? Wieso klappt das bei EXE-Projekten in Delphi, aber offenbar bei
DLL-Projekten nicht? Mache ich denn in der Verwendung was falsch, bspw. auch bei der Konfiguration des
DLL-Projekts?
Ich bin für jede Unterstützung dankbar.