Frage zum "is"-Operator

[QStorm]

Hallo,

Ich habe eine Frage zum "is"-Operator. Soweit ich das nachvollziehen konnte prüft er, ob der Pointer von einem bestimmten Typ ist. Ich würde jedoch gerne wissen ob das Objekt, auf das der Pointer zeigt, von einem bestimmten Typ ist.

Hintergrund: Ich bekomme von TForm.ActiveControl einen Pointer auf ein Objekt, das nicht vom Typ TWinControl ist. Das führt im weiteren Verlauf zu einer Access Violation, da ich auf nicht existente Methoden zugreife.

Wie kann man herausbekommen, ob das Objekt, auf das ein Pointer zeigt, von einem bestimmten Typ ist?

Hier ein Beispiel-Code, mit dem man das ganze nachvollziehen kann:

Code:

procedure TForm1.Button1Click(Sender: TObject);
var
  stringList : TStringList;
  obj     : TObject;
  control : TWinControl;
begin
  stringList := (TStringList.Create);
  obj := TObject(stringList);
  control := TWinControl(obj);
  control.ClassType

  if (control is TWinControl)
  then ShowMessage('True')
  else ShowMessage('False');
end;

Ich habe im Forum und restlichen Internet leider kein passendes Thema gefunden.
Falls es ein doch bereits eines gibt, verzeiht mir den Doppel-Post.

Vielen Dank im Voraus :)

[Sir Rufo]

Delphi-Quellcode:

var
  LWinControl : TWinControl;

if Assigned( Self.ActiveControl ) and ( Self.ActiveControl is TWinControl ) then
begin
  LWinControl := Self.ActiveControl as TWinControl;
  ...
end

[QStorm]

Zitat:

Zitat von Sir Rufo (Beitrag 1245070)

Delphi-Quellcode:

var
  LWinControl : TWinControl;

if Assigned( Self.ActiveControl ) and ( Self.ActiveControl is TWinControl ) then
begin
  LWinControl := Self.ActiveControl as TWinControl;
  ...
end

Das funktioniert leider nicht, da "Self.ActiveControl is TWinControl" True zurück liefert, obwohl das Objekt, auf das "Self.ActiveControl" zeigt, nicht kompatible zu TWinControl ist.

[DeddyH]

Zeig mal Deinen Code, irgendwas erscheint mir da komisch.

[Sir Rufo]

Zeig uns doch mal, was zu dem Zeitpunkt dieses hier zurückgibt

Delphi-Quellcode:

ShowMessage( GetClassInheritancePathFrom( Self.ActiveControl ) );

.

Die Funktion findest du hier http://www.delphipraxis.net/1243656-post12.html

[DeddyH]

Und wenn man wie im obigen Code ein Objekt, dass kein TWinControl ist, einfach hart nach TWinControl castet, ist der Erfolg recht überschaubar.

[Mikkey]

Anscheinend liefert der 'is' immer true, wenn die Referenz den passenden Typ hat, das lässt sich nachvollziehen.

Wenn Du aber den Code in dieser Form abänderst:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  stringList : TStringList;
  obj    : TObject;
  control : TWinControl;
begin
  stringList := (TStringList.Create);
  obj := TObject(stringList);

  if (obj is TWinControl)
  then ShowMessage('True')
  else ShowMessage('False');

  obj := Button1;
  if (obj is TWinControl)
  then ShowMessage('True')
  else ShowMessage('False');
end;

Wird zuerst eine Box mit "false" und dann eine mit "true" gezeigt, so wie man es auch erwarten würde.

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1245080)

Und wenn man wie im obigen Code ein Objekt, dass kein TWinControl ist, einfach hart nach TWinControl castet, ist der Erfolg recht überschaubar.

Die Frage ist eigentlich, wie kommt in

Delphi-Quellcode:

ActiveControl

etwas rein, was nicht von

Delphi-Quellcode:

TWinControl

abgeleitet ist?

[DeddyH]

Keine Ahnung, ich hätte es ja mal versucht, habe aber just in diesem Moment Feierabend :mrgreen:

[himitsu]

Wenn du direkt auf einen Typ prüfen willst, dann mußt du den Typ auch direkt "vergleichen".

z.B.:

Delphi-Quellcode:

if obj.ClassType = TIrgendwas then

if obj.ClassName = 'TIrgendwas' then

if obj.ClassNameIs('TIrgendwas') then

Im Gegensatz zum IS muß man hier aber auf Assigned selber prüfen, auch wenn Emba das im ClassNameIf eigentlich hätte mit aufnehmen können.

Zitat:

Delphi-Quellcode:

if Assigned(obj) and (obj is TIrgendwas) then

Das IS prüft auch auf Assigned.

TRUE = wenn ein Objekt drin ist und wenn es dem Typ entspricht, oder davon abgeleitet wurde.

Das AS läßt aber ein NIL durch, denn NIL könnte man auch als den Typ ansehen, nur daß keine Instanz davon vorhanden ist.
AS knallt also nur, wenn ein "falscher" Typ drin ist.

[QStorm]

Hallo nochmal.

Ich habe noch ein wenig debugged. Folgendes ist herausgekommen:

Nicht "ActiveControl" produziert das Problem. Hier der stark vereinfachte Code:

Code:

var
  ActiveCtrl : TWinControl;
begin
  ActiveCtrl := Self.ActiveControl;
  ShowMessage(GetClassInheritancePathFrom(ActiveCtrl)); // 1
  // UI wird gefüllt oder geleert und dann neu gefüllt
  ShowMessage(GetClassInheritancePathFrom(ActiveCtrl)); // 2
end;

Der Pointer wird durch das Neufüllen der UI/Grid (wahrscheinlich im Grid) geändert. Hier die Ergebnisse von "GetClassInheritancePathFrom"
// 1: TObject->TPersistent->TComponent->TControl->TWinControl->TCustomEdit->TcxCustomInnerTextEdit
// 2: TObject->TPersistent->TComponent->TcxComponent->TcxControlChildComponent->TcxCustomGridView->TcxCustomGridTableView->TcxGridTableView

Hinweis: ActiveControl ist zum zeitpunkt "// 2" = NIL.

Das Problem ist, dass "TcxGridTableView" nicht von "TWinControl" erbt.

[QStorm]

Zitat:

Zitat von himitsu (Beitrag 1245097)

Wenn du direkt auf einen Typ prüfen willst, dann mußt du den Typ auch direkt "vergleichen".

z.B.:

Delphi-Quellcode:

if obj.ClassType = TIrgendwas then

if obj.ClassName = 'TIrgendwas' then

if obj.ClassNameIs('TIrgendwas') then

Das Funktioniert aber nur bei einer flachen Vererbungshierarchie:
Beispiel: TObject -> TMyObject -> TMySubObject

Code:

var
 obj1 : TMyObject;
 obj2 : TMySubObject;
begin
  obj1 := (TMyObject.Create);
  obj2 := (TMySubObject.Create);

  if (obj2.ClassName = 'TMyObject') then; // ist immer False
end;

Vielleicht habe ich mich unglücklich ausgedrückt. Ich möchte wissen ob das Objekt, auf das ein Pointer zeigt, von einem Typ ist oder von diesen erbt. In zum Beispiel Java gibt es instanceof. Das Gegenstück dazu brauche ich in Delphi.

[Sir Rufo]

TObject.InheritsFrom

[Furtbichler]

TcxGridTableView ist kein Control, das zugehörige Control is TcxGrid.

[QStorm]

Zitat:

Zitat von Furtbichler (Beitrag 1245105)

TcxGridTableView ist kein Control, das zugehörige Control is TcxGrid.

Ja das weiß ich. Die Frage ist nur warum der Pointer nach dem Leeren des grids auf TcxGridTableView zeigt.

[Sir Rufo]

Zitat:

Zitat von QStorm (Beitrag 1245106)

Zitat:

Zitat von Furtbichler (Beitrag 1245105)

TcxGridTableView ist kein Control, das zugehörige Control is TcxGrid.

Ja das weiß ich. Die Frage ist nur warum der Pointer nach dem Leeren des grids auf TcxGridTableView zeigt.

Ganz einfach:

Du füllst in einen Eimer Wein, dann schaust du eine Weile nicht hin und ein Anderer säuft den Wein aus und wieder ein Anderer füllt Wasser rein, weil der Eimer ja leer war (ist also Platz gewesen).

Was findest du jetzt in dem Eimer? Aha.

Du hast doch schon selber festgestellt, dass du dir nur eine Referenz (Pointer) auf das Objekt hast und damit kann man das Objekt nicht festhalten, wenn es freigegeben wird.

Ein anderes Beispiel ist eine Visitenkarte von Peter Lustig. Der wohnt nicht in oder auf der Visitenkarte, sondern das ist nur eine Referenz auf seinen Wohnort.
Zieht der Peter jetzt dort aus und dann ein Anderer wieder ein, dadurch wird dieser Andere nicht automatisch zu Peter Lustig.

[QStorm]

Zitat:

Zitat von Sir Rufo (Beitrag 1245107)

Ganz einfach:

Du füllst in einen Eimer Wein, dann schaust du eine Weile nicht hin und ein Anderer säuft den Wein aus und wieder ein Anderer füllt Wasser rein, weil der Eimer ja leer war (ist also Platz gewesen).

Was findest du jetzt in dem Eimer? Aha.

Du hast doch schon selber festgestellt, dass du dir nur eine Referenz (Pointer) auf das Objekt hast und damit kann man das Objekt nicht festhalten, wenn es freigegeben wird.

Ein anderes Beispiel ist eine Visitenkarte von Peter Lustig. Der wohnt nicht in oder auf der Visitenkarte, sondern das ist nur eine Referenz auf seinen Wohnort.
Zieht der Peter jetzt dort aus und dann ein Anderer wieder ein, dadurch wird dieser Andere nicht automatisch zu Peter Lustig.

Mal abgesehen davon das die Beispiele nicht besonders gut gewählt sind, finde ich das ist ein sehr schlechtes Laufzeitverhalten. Wenn ich eine Flasche Wein habe, die jemand austrinkt und danach Wasser reinfüllt, und diese mir dann als Wein verkauft, ist das nichts anderes als Etikettenschwindel.

Zum zweiten Beispiel: Wenn ich eine Referenz auf einen Wohnort von Peter Lustig habe, dann zieht da nach Peter Lustig nicht einfach ein Kaugummi ein, sondern eine andere Person (gleicher Typ).

Ich weiß aber was du damit sagen willst. Dieses Laufzeitverhalten ist dennoch unglücklich und extrem gefährlich. So kann man sich nie darauf verlassen, dass das worauf man zugreift auch das ist was man ursprünglich annahm (insbesondere wenn man mit externen Bibliotheken arbeitet). Leider ist das in vielen Bereichen von Delphi so (siehe Reference Counting von Interfaces, das wohl nur noch Delphi so betreibt).

Naja, da kann man wohl nichts machen.

Vielen Dank für eure Hilfe. :)

[himitsu]

Zitat:

Zitat von QStorm (Beitrag 1245109)

Zum zweiten Beispiel: Wenn ich eine Referenz auf einen Wohnort von Peter Lustig habe, dann zieht da nach Peter Lustig nicht einfach ein Kaugummi ein, sondern eine andere Person (gleicher Typ).

Oder das Haus ist leer und du erwischst einen Geist, (der Speicher ist frei und wurde durch nichts überschrieben)

oder das Haus wird abgerissen und man fällt in ein Loch (Speicher komplett freigegeben, oder irgendwas Anderes ist dort ... z.B. ein Stück eines Strings oder ein Integer)

oder Petra Miesepeter zieht ein (Frau und nicht lustig, also nicht ger gleiche Typ ... original war dort ein Mann)

[Sir Rufo]

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

Du hast hier mit keinem Wort verraten, was zwischen dem 1. und 2. Zugriff passiert.

Delphi-Quellcode:

Application.ProcessMessages

ist z.B. wie den Blick vom Eimer wenden und dann kann dort alles passieren (z.B. die Instanz zur Referenz wird aus dem Speicher geworfen).

Und das ist nur eine der vielen 1000 Möglichkeiten.

Wenn der Bauer nicht schwimmen kann, dann ist natürlich die Badehose Schuld

[JamesTKirk]

Zitat:

Zitat von QStorm (Beitrag 1245102)

Vielleicht habe ich mich unglücklich ausgedrückt. Ich möchte wissen ob das Objekt, auf das ein Pointer zeigt, von einem Typ ist oder von diesen erbt. In zum Beispiel Java gibt es instanceof. Das Gegenstück dazu brauche ich in Delphi.

Das Gegenstück zu instanceof ist nun mal

Delphi-Quellcode:

is

und macht genau das was du beschreibst. :? Vielleicht hast du ganz falsche Erwartungen davon, was da passiert?

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

Delphi-Quellcode:

program tistest;

{$mode objfpc}

uses
  Classes;

var
  stringList : TStringList;
  obj    : TObject;
  control : TInterfacedObject;
begin
  stringList := (TStringList.Create);
  obj := TObject(stringList);
  control := TInterfacedObject(obj); // ich hatte keine Lust Controls einzubinden...
  Writeln(control.ClassType.ClassName);

  Writeln(control is TInterfacedObject); // dürfte unter Delphi glaub ich nicht funktionieren, da das kein Writeln(Boolean) kennt :P
end.

Ausgabe:

Code:

TStringList
FALSE

Gruß,
Sven

[QStorm]

Zitat:

Zitat von JamesTKirk (Beitrag 1245123)

Das Gegenstück zu instanceof ist nun mal

Delphi-Quellcode:

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:

Zitat von JamesTKirk (Beitrag 1245123)

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:

Zitat von Sir Rufo (Beitrag 1245113)

@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

Delphi-Quellcode:

  (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. :thumb:

[Sir Rufo]

Zitat:

Zitat von Furtbichler (Beitrag 1245128)

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 :mrgreen:

[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:

Zitat von Stevie (Beitrag 1245212)

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:

Zitat von QStorm (Beitrag 1245126)

Zitat:

Zitat von JamesTKirk (Beitrag 1245123)

Das Gegenstück zu instanceof ist nun mal

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von QStorm (Beitrag 1245126)

Zitat:

Zitat von JamesTKirk (Beitrag 1245123)

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

Delphi-Quellcode:

intfobjvar is TInterfacedObject

vereinfacht zu

Delphi-Quellcode:

Assigned(intfobjvar)

, weil er davon ausgeht, dass in einer Variable vom Typ

Delphi-Quellcode:

TInterfacedObject

nur eine Instanz vom Typ

Delphi-Quellcode:

TInterfacedObject

oder eines seiner Nachfahren sein kann...
Kannst du dir mal bitte noch das Ergebnis von

Delphi-Quellcode:

obj is TInterfacedObject

ausgeben lassen? Da sollte dann, falls meine Vermutung zutrifft,

Delphi-Quellcode:

False

bei rauskommen.

Gruß,
Sven

[Stevie]

Zitat:

Zitat von JamesTKirk (Beitrag 1245275)

Eventuell kann es sein, dass der Compiler

Delphi-Quellcode:

intfobjvar is TInterfacedObject

vereinfacht zu

Delphi-Quellcode:

Assigned(intfobjvar)

, weil er davon ausgeht, dass in einer Variable vom Typ

Delphi-Quellcode:

TInterfacedObject

nur eine Instanz vom Typ

Delphi-Quellcode:

TInterfacedObject

oder eines seiner Nachfahren sein kann...

Richtig vermutet, bei einem is auf genau die Klasse der Variable oder eine Elternklasse macht der Compiler einfach nur eine Assigned Überprüfung.

[himitsu]

Zitat:

Zitat von Stevie (Beitrag 1245499)

Richtig vermutet, bei einem is auf genau die Klasse der Variable oder eine Elternklasse macht der Compiler einfach nur eine Assigned Überprüfung.

Und wenn nicht, dann gibt es entweder einen Bug und/oder jemand hat böswillig/mutwillig die Typprüfung umgangen.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1245508)

Zitat:

Zitat von Stevie (Beitrag 1245499)

Richtig vermutet, bei einem is auf genau die Klasse der Variable oder eine Elternklasse macht der Compiler einfach nur eine Assigned Überprüfung.

Und wenn nicht, dann gibt es entweder einen Bug und/oder jemand hat böswillig/mutwillig die Typprüfung umgangen.

Ja, auf eine Art irgendwie logisch, dass das so gemacht wird. Ansonsten bringt einem die ganze Typensicherheit auch nix, wenn man an jeder Ecke doch noch nachschauen muss, obs stimmt.