TObject kein ordinaler Typ?

[Stevie]

Zitat von Muetze1:

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

If Integer in [Integer, Integer, Integer] Then ... Beide Seiten des 'IN'-Operators sind vom Typ her identisch. Klar geht das.

If TObject in [Integer, Integer, Integer] Then ... Äh. Beide Seiten des 'IN'-Operators sind nicht typkompatibel. Ich komme darauf zurück.

If TObject in [TObject , TObject , TObject ] Then ... Gottseidank meckert wenigstens da der Compiler, vonwegen "ordinaler Typ erforderlich".

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. Hupsa. Eine <ObjectRef> ist doch aber kein Ordinalwert. Oder?

Um also himitsus Frage aufzugreifen

Zitat von himitsu:

Warum?

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

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
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.