Überprüfen ob ein Objekt existiert aber wie?

[Furtbichler]

Wie böser kann man eigentlich werden, also böser als *Böse*? Nicht das das hier abfärbt und irgendwie ein Eigenleben entwickelt.

Nichtsdestotrotz: Richtiger Einwand.

[derMischka]

zu meiner Verteidigung:

Da das Ergebnis mit False oben initialisiert ist, braucht man die "nur lesende" Funktion in der Exception-Klammer ncht weiter behandeln --> es wurde kein Code verändert (da nur gelesen) und bei einer Exception ist das richtige Ergebnis (False) ja schon im Register eax.

der Mischka

[nahpets]

Besser? Oder auch noch böse?

Delphi-Quellcode:

function ObjectExists(aObj: TObject): boolean;
begin
  Result := aObj <> nil;
  if Result then
  try
    Result := aObj.InheritsFrom(TObject);
  except
    Result := false;
  end;
end;

[Sir Rufo]

Zitat von nahpets:

Besser? Oder auch noch böse?

Delphi-Quellcode:

function ObjectExists(aObj: TObject): boolean;
begin
  Result := aObj <> nil;
  if Result then
  try
    Result := aObj.InheritsFrom(TObject);
  except
    Result := false;
  end;
end;

Das Problem liegt doch darin begründet, dass diese Funktion nicht zuverlässig funktioniert.
Es ist reine Glückssache.

Wenn du einen Zufallsgenerator haben möchtest, ist das eine tolle Funktion.
Für die Überprüfung, ob an der Speicherstelle auf die die Referenz zeigt eine gültige Instanz vorliegt, taugt die nicht die Bohne.

Das Warum findet sich in den Beiträgen hier erläutert

[nahpets]

Zitat von Sir Rufo:

Zitat von nahpets:

Besser? Oder auch noch böse?

Das Warum findet sich in den Beiträgen hier erläutert

Ok, auch böse und wer lesen kann ist klar im Vorteil, stelle mich sofort in die Ecke und schäme mich

[Medium]

Halten wir doch einfach hier fest:
Eine gültige von einer ungültigen Referenz zu unterscheiden ist im allgemeinen Fall unmöglich, es sei denn man achtet SELBST darauf entweder den Zeiger bei Freigabe zu NILen, oder zumindest den Speicherbereich so zu deformieren, dass solch ein try...ecxept klappen kann. Der einzige andere Weg wären entweder Interfaces (danke Referenzzählung), oder eine eigene Implementierung einer Basisklasse, die ähnlich wie Interfaces agiert.

In praktisch allen anderen Fällen ist es immer möglich, dass ein freigegebenes Objekt zum Prüfzeitpunkt unangetastet im Speicher stehen geblieben ist, womit für das laufende Programm ohne Metainformationen keine Möglichkeit besteht eine Referenz auf diesen Speicherbereich als ungültig zu erkennen, da sowohl die Referenz als auch der referenzierte Speicher exakt gleich aussehen können wie vor der Freigabe des Objektes. End of Story.

(Man könnte höchstens noch versuchen sich in den Speichermanager zu hängen, um dort zu gucken ob die entsprechenden Blöcke als frei markiert wurden. Aber selbst dann: Es könnte dort bereits ein neues Objekt erstellt worden sein, so dass der Speicher als belegt zählt, und schon würde man wieder auf die Nase fallen. Am Ende also auch nur ein schöner Trick, der aber nicht allgemeingültig funktioniert.)

[Furtbichler]

ES gibt zudem kein Einsatzbeispiel, wo es nicht ausreicht, auf '<>Nil' zu prüfen.

Mit anderen Worten: Programmiert einfach so, das sich diese Frage nie stellt, d.h. Kopiert einfach keine Instanzen, wenn während der Lebensdauer der Kopie die Möglichkeit besteht, dass das Original freigegeben wird.

Der Zugriff auf Objekte sollte zudem i.A. immmer über den Eigentümer der Instanz erfolgen, dann kann nichts schiefgehen. Man muss dann nur im Eigentümer die Logik der Lebensdauer implementieren.