Zugriffsverletzung beim Zerstören der TIniFile-Instanz

[TheSledgeHammer]

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.