Forum: Object-Pascal / Delphi-Language
Delphi
by himitsu,
10. Mär 2020
Klar kann man sowas machen, aber "logisch" ist es dann nicht, warum
if a = b then nicht das gleiche Ergebnis liefert, wie if not (a <> b) then.
Außer du fängst da mit einer Tristate-Logic oder mehr an
ungleich, fast gleich, gleich, gleicher, ganz gleich, identisch
OK, kennt man z.B. aus PHP
if (0 == '0') // true
Forum: Object-Pascal / Delphi-Language
Delphi
by himitsu,
10. Mär 2020
Es geht ja noch weiter ... Delphi/Pascal kennt keine Unterscheidung zwischen Bitwise und Logical, bei and/or/xor, aber du kannst beides Deklarieren (für das komische BCPP),
was erstmal nicht schlimm ist, wenn dir der Compiler eine Meldung geben würde, dass er das Andere nicht verwendet.
Oder wenn du Equal deklariert hast, dann könnte man das für NotEqual mitverwenden, wenn dieses nicht...
Forum: Object-Pascal / Delphi-Language
Delphi
by himitsu,
9. Mär 2020
JA, WENN man diesen Operator einbaut.
Aber stell dir mal vor das wäre Intelligent und würde den ImplicitCast benutzen.
Und wierum hat einen großen Einfluss auf die Qualität des Vergleichs. (siehe TTest2)
In meinem Fall kann dieses Verhalten sogar einen Fehler erzeugen, wenn sich der Record nicht in einen Integer casten lässt.
Geht doch, denn hier wird natürlich der ImplicitCast...
Forum: Object-Pascal / Delphi-Language
Delphi
by himitsu,
9. Mär 2020
Warum kann der Compiler nicht auch mal etwas Intelligenz zeigen und den impliziten Cast benutzen, anstatt beim if List = 0 then aufzugeben?
Andersrum geht if 0 = List then zum Glück auch nicht, obwohl der Compiler dort ja schon weiß, dass der Vergleich einen Integer ordinalen Typen haben möchte.
type
TTestItem = record
private
FValue: Integer;
function GetValue: Integer;
...
