Frage zum "is"-Operator

[QStorm]

Zitat von JamesTKirk:

Das Gegenstück zu instanceof ist nun mal is und macht genau das was du beschreibst. Vielleicht hast du ganz falsche Erwartungen davon, was da passiert?

Eben nicht, denn "instanceof" prüft ob das referenzierte Objekt zuweisungskompatibel zu einer Klasse ist. "is" hingegen prüft lediglich, ob die Referenz/Pointer zuweisungskompatibel ist (wie man in meinem Beispiel schön sieht). "TObject.InheritsFrom" macht genau das was ich brauche.

Zitat von JamesTKirk:

Ich hab mal dein Beispiel von Anfang (ein bisschen abgeändert) getestet:

Ich habe dein abgeändertes Beispiel ausgeführt. Die Ausgabe ist jedoch anders, als du schreibst:

Code:

TStringList
TRUE

[QStorm]

Zitat von Sir Rufo:

@QStorm
Wenn man weiß, was man macht, bzw. was man zulässt, dann ist das kein Problem.

Leider kann man das in komplexen Projekten insbesondere in Zusammenspiel mit externen Bibliotheken nicht immer wissen/überschauen.

In dem Beispiel mag das vielleicht noch gehen aber wie du schreibst gibt es 1000 Möglichkeiten, die du bestimmt auch nicht immer im Kopf hast.

OK vielen Dank nochmal für die Hilfe.

P.S.: Der Bauer kann schwimmen, ist nur nicht an eine Badehose voller Blei gewöhnt.

[Furtbichler]

Was glaubt ihr wohl, was rauskommt, wenn ich über einen Besenstiel eine Maske von Justin Bieber stülpe? Eben. Vollkommener Trash. In Delphi:

Delphi-Quellcode:

if TJustinBieber(BesenStiel) is TJustinBieber then
  writeln('Wer hätte das gedacht');

Das ist der sog. 'harte Karsten' (oder engl: hard casting), und der funktioniert immer, daher ist das auch ziemlich dreist, so etwas zu tun und man muss schon wissen, was man macht. Praktisch ist der harte Karsten eigentlich nur, wenn man Speicherbereiche interpretieren will.

Bei Objekten verwendet man den 'as' Operator, der fragt nämlich freundlich nach (bzw. prüft) ob der Besenstiel überhaupt Willens und in der Lage ist, den Justin Bieber zu machen, was er natürlich nicht ist (einerseits ist der Besenstiel viel zu intelligent und zweitens liegt es nicht in seiner Natur, zu singen und sich daneben zu benehmen).

Aber nehmen wir mal, sagen wir, den Wendler und fragen ihn aber:

Delphi-Quellcode:

if (DerWendler Is TJustinBieber) then // hier kann der harte Karsten wieder ran
   TJustinBieber(DerWendler).SingUnsEinen();

Die Variante   (DerWendler as TJustinBieber).SingUnsEinen() würde mit einem invaliden Karsten antworten (EInvalidCastException), falls ER (der Wendler) uns wider Erwarten den Bieber Justin nicht machen kann, was sehr unwahrscheinlich ist, denn vom Niveau her sollte das schon passen.

Ach: Und zum eigentlichen Problem:

Das Zwischenspeichern von Eigenschaften einer anderen Klasse, während diese verändert wird, ist schlicht und ergreifend falsch. Das 'ActiveControl' der Form gibt zu jedem Zeitpunkt korrekt wieder, welches Control den Fokus hat und daher sollte man es auch so verwenden. Alles(!) andere ist schlicht und ergreifend fahrlässig.

PS: Der Bauer sollte sich erstmal an die Strandregel halten und überhaupt eine Badehose tragen.

[QStorm]

@Furtbichler: Danke für die (wenn auch etwas zu sehr ausgeschmückte) Erklärung zu "as".
P.S.: Der Bauer ist dabei sich an die (an anderen Stränden weitaus besser verfassten) Strandregeln zu halten. Das ist jedoch ein Lernprozess und nicht von heute auf morgen geschehen.

[Gushiken]

@Furtbichler: Großartig. Ganz großes Kino Auch wenn DerWendler vielleicht ein schlechtes Beispiel ist... Der macht doch alles um nicht ganz von der Bildoberfläche zu verschwinden, also wird es niemals einen invaliden Karsten geben
Eine sehr amüsante und gute (!) Erklärung vom Unterschied zwischen as und dem harten Karsten.

[Sir Rufo]

Zitat von Furtbichler:

PS: Der Bauer sollte sich erstmal an die Strandregel halten und überhaupt eine Badehose tragen.

Aber dann kommt ja nicht die Bay(Instance)watch-Dame mit den blonden Beinen und den langen Hupen vorbei

[Stevie]

Um mal wieder zum Ursprungsproblem zu kommen.

Ich kann das bei mir mit der DevExpress 13.1.12 nicht nachstellen, dort zeigt bei einem leeren Grid ActiveControl auf ein TcxGridSite Control (was von TWinControl abgeleitet ist). Ich vermute also einen Bug in DevExpress, denn etwas, was nicht von TWinControl erbt in ActiveControl zu packen dürfte unzulässig sein.

P.S. Nachdem ich diesen 10 Jahre(!) alten KB Artikel gefunden habe, denke ich, das wird kein Bug in DevExpress sein.

[QStorm]

Zitat von Stevie:

Um mal wieder zum Ursprungsproblem zu kommen.

Ich kann das bei mir mit der DevExpress 13.1.12 nicht nachstellen, dort zeigt bei einem leeren Grid ActiveControl auf ein TcxGridSite Control (was von TWinControl abgeleitet ist). Ich vermute also einen Bug in DevExpress, denn etwas, was nicht von TWinControl erbt in ActiveControl zu packen dürfte unzulässig sein.

P.S. Nachdem ich diesen 10 Jahre(!) alten KB Artikel gefunden habe, denke ich, das wird kein Bug in DevExpress sein.

Hallo,

Danke für den Link. Sehr interessant.

Das Problem ist ein anderes: Ich habe mir eine Referenz auf das aktive Control geholt (via TForm.ActiveControl). Danach wurde die UI geleert. Das aktive Control wurde dabei abgeräumt, was dazu führt, dass die Referenz auf Datenmüll im Speicher zeigt.

[DeddyH]

So etwas nennt sich dangling pointer oder wilder Zeiger. Den erkennt man auch mit einer Assigned-Abfrage nicht, da er ja weiterhin zugewiesen ist, auch wenn das Zielobjekt nicht mehr existiert. Aus diesem Grund muss man mit mehreren Referenzen auf dasselbe Objekt immer sehr vorsichtig sein oder sie wenn möglich gleich ganz vermeiden.

[JamesTKirk]

Zitat von QStorm:

Zitat von JamesTKirk:

Das Gegenstück zu instanceof ist nun mal is und macht genau das was du beschreibst. Vielleicht hast du ganz falsche Erwartungen davon, was da passiert?

Eben nicht, denn "instanceof" prüft ob das referenzierte Objekt zuweisungskompatibel zu einer Klasse ist. "is" hingegen prüft lediglich, ob die Referenz/Pointer zuweisungskompatibel ist (wie man in meinem Beispiel schön sieht). "TObject.InheritsFrom" macht genau das was ich brauche.

Dann guck dir mal die Implementierung von is in FPC an:

Delphi-Quellcode:

    function fpc_do_is(aclass : tclass;aobject : tobject) : boolean;[public,alias: 'FPC_DO_IS']; compilerproc;
      begin
         fpc_do_is:=assigned(aobject) and assigned(aclass) and
           aobject.inheritsfrom(aclass);
      end;

Zitat von QStorm:

Zitat von JamesTKirk:

Ich hab mal dein Beispiel von Anfang (ein bisschen abgeändert) getestet:

Ich habe dein abgeändertes Beispiel ausgeführt. Die Ausgabe ist jedoch anders, als du schreibst:

Code:

TStringList
TRUE

Eventuell kann es sein, dass der Compiler intfobjvar is TInterfacedObject vereinfacht zu Assigned(intfobjvar) , weil er davon ausgeht, dass in einer Variable vom Typ TInterfacedObject nur eine Instanz vom Typ TInterfacedObject oder eines seiner Nachfahren sein kann...
Kannst du dir mal bitte noch das Ergebnis von obj is TInterfacedObject ausgeben lassen? Da sollte dann, falls meine Vermutung zutrifft, False bei rauskommen.

Gruß,
Sven