Delphi 7 Hack für Assigned -> Ersatz für Delphi 2010 gesucht

[knochen]

Hallo zusammen.

In unserer Delphi 7 Applikation gibt es eine Funktion, die unter Delphi 7 funktionierte. Möglicherweise ein Hack aus einer Computerzeitschrift oder einem Forum.
Code folgt:

Delphi-Quellcode:

{
Prüft ein Objekt auf einen NIL-Pointer (assigned) und auf
die Gültikeit des Zeigers (SizeOfMem)

Eingabeparameter
    ppeObjRef : zu prüfendes Objekt
Rückgabe
    Boolean --> Objekt-Rferenz gültig oder nicht

}

function ObjektAssigned(ppeObjRef: TObject): Boolean;
type
  PPVmt = ^PVmt;
  PVmt = ^TVmt;
  TVmt = record
    SelfPtr: TClass;
    Other: array[0..17] of Pointer;
  end;
var
  Vmt: PVmt;
begin
  Result := False;
  if Assigned(ppeObjRef) then
  begin
    try
      Vmt := PVmt(ppeObjRef.ClassType);
      Dec(Vmt);
      Result := ppeObjRef.ClassType = Vmt.SelfPtr;
    except
      // Exception ignorieren, Result ist False
    end;
  end;
end;

Die Problematik ist Folgende:
Wenn ein Objekt mit MyObject.Free freigegeben wird, wird von Assigned(MyObject) immer noch True zurückgegeben, obwohl das Objekt schon im Nirwana ist. Obige Funktion gibt in einem solchen Fall False zurück, und das ist genau das gewünschte Verhalten.
Unter Delphi 7 hat das sehr schön funktioniert, aber unter Delphi 2010 knallt's.
Kennt jemand diesen Hack und weiß, wie man ihn auf Delphi 2010 portiert?
Die Funktion FreeAndNil() ist mir bekannt und ich würde sie im äußersten Notfall auch einsetzen, aber wenn es irgend geht dann lieber nicht.

Vielen Dank im Voraus

[Bernhard Geyer]

Zitat von knochen:

Die Funktion FreeAndNil() ist mir bekannt und ich würde sie im äußersten Notfall auch einsetzen, aber wenn es irgend geht dann lieber nicht.

Und wieso nicht? Sie wurde genau deshalb eingeführt um keine ungültigen Referenzen mehr übrig zu lassen.

[Neutral General]

Deine Funktion funktioniert bei mir übrigens auch unter Delphi7 nicht:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var tmp: TObject;
begin
  tmp := TObject.Create;
  tmp.Free;

  if Assigned(tmp) then
    ShowMessage('Assigned nachher!');
  if ObjektAssigned(tmp) then
    ShowMessage('ObjektAssigned nachher!');
end;

Beide MessageBoxen werden angezeigt.

[Bernhard Geyer]

Zitat von Neutral General:

Deine Funktion funktioniert bei mir übrigens auch unter Delphi7 nicht:

Evtl. FastMM eingebunden und Debug aktiv? Ich denke solche Hacks funktionieren nicht wenn ein anderer Memory-Manager aktiv ist.

[himitsu]

Tja, es hat sich da halt auch mal was verändert.
(neue RTTI, anderer Speichermanager uwm.)

A: Außerdem waren solche Funktionen eh nie zu 100% zuverläßig

und B: sollte man schon immer in soeinem Fall, wo der Zeiger nach dem Freigeben via Assign geprüft werden soll, FreeAndNil verwenden. Dann ist der Zeiger auch schön NIL.

PS: Wenn zufällig ein ein anders Objekt in der Zwischenzeit den selben Speicherplatz belegt, dann dann würde deise Prüfung auch TRUE liefern, da ja "irgendein" Objekt vorhanden ist.

Zitat:

Beide MessageBoxen werden angezeigt.

tja, wenn der Speicher nicht vom Speichermanager freigegeben wurde und wenn der Speicher nicht überschrieben wurde, dann steht im Speicher immernoch die Signatur, welche hier geprüft wird ... ergo: die Funktion sagt JA.

[Hawkeye219]

Hallo,

eine garantiert zuverlässige Funktion gibt es möglicherweise nicht, eine Alternative für D2010 schon: klick

FreeAndNil ist sicher die bessere Lösung, und auch darauf kann man in den meisten Fällen verzichten, wenn der Code sauber aufgebaut ist. Im EDN gab es dazu mehrere Threads, in denen unter anderem Joanna Carter einige nützliche Hinweise gegeben hat.

Gruß Hawkeye

[himitsu]

Zitat von Hawkeye219:

eine garantiert zuverlässige Funktion gibt es möglicherweise nicht, eine Alternative für D2010 schon: klick

Nur ob dieses dann unter Delphi 2012 noch läuft, ist eine andere Sache ... dann doch lieber gleich richtig .Free und FreeAndNil verwenden (jenachdem was benötigt wird).

[knochen]

Was ich mir schon seit ca. 13 Jahren wünsche (Delphi 2), ist ein Compiler- oder IDE-Schalter, der ein Objekt automatisch nilt, wenn ich Free aufrufe. Da werden über die Jahre Features eingebaut, die vor Mächtigkeit nur so strotzen, aber dieses kleine, oft gewünschte und unermesslich nützliche Feature kriegt die Compilercompany nicht hin? - Aua.

So, jetzt zum konstuktiven Teil.
FreeAndNil ist die bessere Alternative, keine Frage!

Zu uns: wir haben ca. 500 MB Quelltexte, historisch gewachsen. Zwei primäre Gründe haben mich zu der Frage veranlasst.
1. Die Destruktoren heißen nicht immer Free.
2. Die Sourcen sind zu ca. einem Viertel generiert.

Auf jeden Fall danke ich euch für eure Vorschläge und Verweise auf andere Threads. Den Vorschlag von Hawkeye219 werde ich auf jeden Fall mal ausprobieren.

[schlecki]

Zitat von knochen:

Zu uns: wir haben ca. 500 MB Quelltexte, historisch gewachsen. Zwei primäre Gründe haben mich zu der Frage veranlasst.
1. Die Destruktoren heißen nicht immer Free.

Genau genommen heißen sie niemals Free, sondern _immer_ Destroy

[Bernhard Geyer]

Zitat von knochen:

Was ich mir schon seit ca. 13 Jahren wünsche (Delphi 2), ist ein Compiler- oder IDE-Schalter, der ein Objekt automatisch nilt, wenn ich Free aufrufe.

Das gibt es. Nennt sich Delphi.Prism.

Zitat von knochen:

Da werden über die Jahre Features eingebaut, die vor Mächtigkeit nur so strotzen, aber dieses kleine, oft gewünschte und unermesslich nützliche Feature kriegt die Compilercompany nicht hin? - Aua.

Also ich habe das nicht vermisste. Dort wo es nötig ist bau ich FreeAndNil ein und dort wo es nicht nötig ist lass ich es so.

Zitat von knochen:

Zu uns: wir haben ca. 500 MB Quelltexte, historisch gewachsen. Zwei primäre Gründe haben mich zu der Frage veranlasst.
1. Die Destruktoren heißen nicht immer Free.

Der Destruktor heiß nie Free. Er heißt eigentlich fast immer Destroy! Free ist eh schon ein Hilfskonstrukt mit folgenden Quellcode

Delphi-Quellcode:

  if Self <> nil then
    Destroy;

Zitat von knochen:

2. Die Sourcen sind zu ca. einem Viertel generiert.

Das sollte es ja kein Problem sein jeden Free-Aufruf durch FreeAndNil() zu ersetzen.

Zitat von knochen:

Auf jeden Fall danke ich euch für eure Vorschläge und Verweise auf andere Threads. Den Vorschlag von Hawkeye219 werde ich auf jeden Fall mal ausprobieren.

Du willst doch nicht den einen problematischen Hack durch den nächsten Ersetzen?