TObject kein ordinaler Typ?

[himitsu]

Moin,

ich mach's mal kurz und schmerzlos.

Dieses geht,

Delphi-Quellcode:

If Integer(Components[i]) in [Integer(Panel1), Integer(Panel2), Integer(Panel3)] Then Begin

komischer Weise auch Jenes,

Delphi-Quellcode:

If Components[i] in [Integer(Panel1), Integer(Panel2), Integer(Panel3)] Then Begin

aber das nicht,

Delphi-Quellcode:

If Components[i] in [Panel1, Panel2, Panel3] Then Begin

jedenfalls meckert da der Compiler, vonwegen "ordinaler Typ erforderlich". :gruebel:


Warum?

[Stevie]

Weil Sets nur mit ordinalen Typen funktionieren und ein Objekt kein ordinaler Typ ist.

[Namenloser]

Aus dem gleichen Grund, weshalb du nicht Panel2 := Panel1+1 schreiben kannst, würde ich mal vermuten. :roteyes:

[himitsu]

Zitat:

Zitat von Stevie

und ein Objekt kein ordinaler Typ ist.

Eine Objektinstanz ist ein Pointer,
ein Pointer ist eine Zahl (Cardinal)
und eine Zahl ist ein ordinaler Typ.

Zitat:

Panel2 := Panel1+1

Das bedeutet nur, daß für diesen Typen keine Arithmetik implementiert ist,
aber intern ist es dennoch ein ordinaler Typ.

[Stevie]

Zitat:

Zitat von himitsu

Zitat:

Zitat von Stevie

und ein Objekt kein ordinaler Typ ist.

Eine Objektinstanz ist ein Pointer,
ein Pointer ist eine Zahl (Cardinal)
und eine Zahl ist ein ordinaler Typ.

Rat mal, warum man eine Object-Referenz explizit casten muss, wenn mans z.B. in der Property Tag speichern möchte?
Richtig, weil Objekt-Referenzen nicht implizit zuweisungskompatibel zu diesem Datentyp sind (Stichwort Typensicherheit).
Daher gehen auch deine beiden oberen Beispiele, in denen du die Objekt-Referenzen explizit in Integer umcastest, aber im unteren Beispiel versucht der Compiler ein Set zu bauen, geht aber nicht, weils sich ebend nicht in nen ordinalen Typen handelt.

[Neutral General]

Kann man das mit den Sets überhaupt so machen?

Gabs da nicht sone "Regel" die besagte, dass Sets nicht mit Datentypen > 1 Byte verwendet werden soll(t)en ?
Oder verwechsel ich da (wieder) was?

[Stevie]

Zitat:

Zitat von Neutral General

Kann man das mit den Sets überhaupt so machen?

Gabs da nicht sone "Regel" die besagte, dass Sets nicht mit Datentypen > 1 Byte verwendet werden soll(t)en ?
Oder verwechsel ich da (wieder) was?

Nein, das stimmt, die Ausdrücke von Himi würden eh nicht hinhauen, weil die auf Integer umgecasteten Objekt-Referenzen auf 1 Byte verkürzt würden.

[Muetze1]

Zitat:

Zitat von Stevie

Nein, das stimmt, die Ausdrücke von Himi würden eh nicht hinhauen, weil die auf Integer umgecasteten Objekt-Referenzen auf 1 Byte verkürzt würden.

1 Byte? Was? Wo?

Integer sind 4 Bytes und die kann er nicht weiter kürzen, weil dann signifikante Stellen verloren gehen. Da würde er warnen und man müsste einen expliziten Cast machen. Implizite Casts macht er nur, wenn keine signifikante Stellen verloren gehen (wie in allen Programmiersprachen). Aber 1 Byte? Wie kommst du auf den Wert?

[Namenloser]

Zitat:

Zitat von himitsu

Zitat:

Panel2 := Panel1+1

Das bedeutet nur, daß für diesen Typen keine Arithmetik implementiert ist,
aber intern ist es dennoch ein ordinaler Typ.

Nunja, intern ist so ziemlich alles ein ordinaler Typ. Du kannst auch einen String auf Integer casten und anschließend inkrementieren.

[3_of_8]

Zitat:

Zitat von Muetze1

Zitat:

Zitat von Stevie

Nein, das stimmt, die Ausdrücke von Himi würden eh nicht hinhauen, weil die auf Integer umgecasteten Objekt-Referenzen auf 1 Byte verkürzt würden.

1 Byte? Was? Wo?

Integer sind 4 Bytes und die kann er nicht weiter kürzen, weil dann signifikante Stellen verloren gehen. Da würde er warnen und man müsste einen expliziten Cast machen. Implizite Casts macht er nur, wenn keine signifikante Stellen verloren gehen (wie in allen Programmiersprachen). Aber 1 Byte? Wie kommst du auf den Wert?

Es geht hier aber um Sets, und ein Set über einen 4 Byte großen Zahlentyp kannst du vergessen. ;)

[Stevie]

Zitat:

Zitat von Muetze1

Zitat:

Zitat von Stevie

Nein, das stimmt, die Ausdrücke von Himi würden eh nicht hinhauen, weil die auf Integer umgecasteten Objekt-Referenzen auf 1 Byte verkürzt würden.

1 Byte? Was? Wo?

Integer sind 4 Bytes und die kann er nicht weiter kürzen, weil dann signifikante Stellen verloren gehen. Da würde er warnen und man müsste einen expliziten Cast machen. Implizite Casts macht er nur, wenn keine signifikante Stellen verloren gehen (wie in allen Programmiersprachen). Aber 1 Byte? Wie kommst du auf den Wert?

Probier mal folgendes:

Delphi-Quellcode:

procedure Test;
var
  i, k: Integer;
begin
  i := MaxInt;
  k := MaxInt;
  if k in [Integer(i)] then
  begin
    ShowMessage('Integer');
  end;
  k := 255;
  if k in [Integer(i)] then
  begin
    ShowMessage('Byte');
  end;
end;

[Muetze1]

Zitat:

Zitat von 3_of_8

Es geht hier aber um Sets, und ein Set über einen 4 Byte großen Zahlentyp kannst du vergessen. ;)

Aber das macht der Compiler nicht von Haus aus, sondern er warnt vorher bzw. bei Sets mit zu großen Enums (mehr als 64 Elemente) bricht er sogar mit einem Compilerfehler ab. Der Pascal Compiler legt die Größen seiner Elemente so fest, wie er sie braucht. Also ein Enum kann von 1 Byte bis 4 Byte groß sein, ganz abhängig von der Anzahl der Elemente. Beim Set ist es genauso, alles zwischen 1 Byte bis 8 Bytes, da jedes Set Element in einem Bit zugeordnet wird. Alles klar soweit, aber wo hier nun eine Verkürzung auf 1 Byte vorgenommen wird, das sehe ich noch immer nicht. Also bitte klärt mich auf...

[himitsu]

Zitat:

if k in [Integer(i)] then

also hier warnt der Compiler vor nix ... ist ja voll nett.

[Muetze1]

Mit anderen Worten: Meine Aussagen ist die Theorie, nur CodeGear hat mal wieder Mist gebaut (beim Umsetzen in die Praxis) und gibt keine Warnung aus. Wieder was gelernt - und ein neues Manko einer doch so typensicheren Sprache...

[Stevie]

Zitat:

Zitat von Delphi-Hilfe

Sets may have at most 256 elements

This error message appears when you try to declare a set type of more than 256 elements. More precisely, the ordinal values of the upper and lower bounds of the base type must be within the range 0..255.

[Muetze1]

Es ist aber doch schwachsinnig hier eine compile-time only Meldung einzubauen anstatt auch den runtime Fall mit abzuprüfen.

[Mithrandir]

Aktiviert man in den Compileroptionen die Bereichsüberprüfung, bekommt man die Meldung:

Code:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt Project1.exe ist eine Exception der Klasse ERangeError mit der Meldung 'Fehler bei Bereichsprüfung' aufgetreten.
---------------------------
Anhalten   Fortsetzen   Hilfe   
---------------------------

[alzaimar]

Hi himitsu,

ich möchte mal auf deinen Eingangspost eingehen. Dazu ersetze ich die Variablen durch ihre Typbezeichnungen. Dadurch wird der Code zwar syntaktisch falsch, aber vielleicht fällt unseren Spezialisten dann auf, das sie mit ihrer Diskussion über Mengen nicht gerade zur Aufhellung dieses Delphi-Fehlers(?) beigetragen haben:

Delphi-Quellcode:

If Integer in [Integer, Integer, Integer] Then ...

Beide Seiten des 'IN'-Operators sind vom Typ her identisch. Klar geht das.

Delphi-Quellcode:

If TObject in [Integer, Integer, Integer] Then ...

Äh. Beide Seiten des 'IN'-Operators sind nicht typkompatibel. Ich komme darauf zurück.

Delphi-Quellcode:

If TObject in [TObject , TObject , TObject ] Then ...

Gottseidank meckert wenigstens da der Compiler, vonwegen "ordinaler Typ erforderlich". :gruebel:

Wieso geht das Konstrukt '<ObjectRef> IN <OrdinalSet>' durch den Compiler? Hmm. Mal sehen, was die Delphi-OH dazu sagt:
In der Tabelle der Mengenoperatoren steht bei 'IN', das die Operatorn "Ordinalwert, Menge" sein müssen. :gruebel: Hupsa. Eine <ObjectRef> ist doch aber kein Ordinalwert. Oder? :shock:

Um also himitsus Frage aufzugreifen

Zitat:

Zitat von himitsu

Warum?

Würde ich derzeit mit einem 'Weil Irgendwer bei BorlInpCodeGarcadero mal geschlampt hat' beantworten.
:wall:

Zitat:

Zitat von Stevie

... weil Objekt-Referenzen nicht implizit zuweisungskompatibel zu diesem Datentyp sind (Stichwort Typensicherheit)

Das stimmt dann wohl nicht.

[Stevie]

Ich weiß ja nicht, ob du es ausprobiert hast, oder es einfach geglaubt hast.
Eventuell ist es auch einfach nur zu früh für mich, aber

Delphi-Quellcode:

if Components[i] in [Integer(Panel1), Integer(Panel2), Integer(Panel3)] then ...

gibt bei mir einen "E2010 Inkompatible Typen: 'TComponent' und 'Integer'" compiler error.
Somit dürfte meine Aussage nach wie vor stehen.

Schau dir außerdem einmal den asm an, der für ein in-Statement erzeugt wird, dann siehst du, warum ein Hardcast eines 32-Bit Pointers auf ein Integer nix bringt (und warum in der OH das von mir zitierte steht)

[himitsu]

Hatte es ausprobiert, aber wegen eines Fehlers im Set war ich da nicht bis Then gekommen, so daß diese Fehlermeldung noch nicht angezeigt wurde.

[alzaimar]

Zitat:

Zitat von Stevie

Ich weiß ja nicht, ob du es ausprobiert hast, oder es einfach geglaubt hast.

himitsu habe ich es einfach geglaubt.

Zitat:

Zitat von Stevie

Eventuell ist es auch einfach nur zu früh für mich, aber

Nee, für mich. Denn normalerweise prüfe ich das auch.

Zitat:

Zitat von Stevie

Somit dürfte meine Aussage nach wie vor stehen.

Jupp. Nehme alles zurück und behaupte das Gegenteil.