![]() |
TRUE/FALSE Part
Sorry bestimmt schon oft besprochen..
Aber destotrotz! Warum sollte man tunlichst auf das prüfen von True und False verzichten. Kosmetisches Problem oder was steckt da hinter?
Delphi-Quellcode:
If Foo = True then
Delphi-Quellcode:
if Foo then
Delphi-Quellcode:
If Foo = False then
Delphi-Quellcode:
if not Foo then
Was macht jetzt den Unterschied ? gruss |
AW: TRUE/FALSE Part
False ist als 0 deklariert -> True ungleich 0.
Delphi verwendet hierfür 1, C ( also auch WinaAPI) -1 ( als binäres Komplement zu 0) 1 ist aber <> -1 -< True ist nicht gleich True. |
AW: TRUE/FALSE Part
|
AW: TRUE/FALSE Part
Zitat:
Delphi-Quellcode:
prüfst, dann prüft Du, ob Foo den Booleanwert TRUE hat.
If Foo = True then
Wenn Du
Delphi-Quellcode:
auswertest, dann prüft Du, ob die Auswertung von Foo "Wahr" ergibt.
If Foo then
Und tunlichst darauf verzichten halte ich für falsch, denn es gibt Situationen, in denen man direkt auf TRUE prüfen muss. |
AW: TRUE/FALSE Part
Zitat:
|
AW: TRUE/FALSE Part
Zitat:
Solange ich in Delphi arbeite ist True = 1 Was spricht also gegen die Prüfung von if Foo = True then welchen zustand kann ich denn solange ich in Delphi unterwegs bin noch erreichen als 1 Würde ich innerhalb Delphi mit mehreren API's unterwegs sein also bsp. C++.dll könnte ich verstehen das hier eventuell inkonsistenten entstehen. Aber so? Doch kosmetische Sache? gruss |
AW: TRUE/FALSE Part
Ein Delphi-Boolean ist intern als ein Byte (1 Byte) deklariert, denn die kleinste "adressierbare" Speicherheinheit ist nunmal ein Byte.
Der BOOL in C++ ist intern als ein INT (Integer, 4 Byte) deklariert. Die Boolean-Variablen haben also nicht zwei Zustände, sondern 256. Einer davon ist False, da das immer 0 ist. "Wahr" ist dagegen als ungleich 0, bzw. "nicht Falsch" definiert. Die Konstante "True" ist in Delphi aber als 1 deklariert. (kann halt nur einen Wert besitzen)
Delphi-Quellcode:
var
B: Boolean; B := True; if B then Beep; if not B then Beep; if B = True then Beep; // hast du ein Glück gehabt, daß es "zufällig" genau 1 ist if B = False then Beep; B := Boolean(2); if B then Beep; if not B then Beep; if B = True then Beep; // nänänänänäääääääää if B = False then Beep; if B <> False then Beep; Du kannst niemals sagen, ob der Wert nicht doch aus irgendeiner API kommt, ober über Assembler oder sonstwelche bösen Casts erzeugt wurde. Darum einfach grundsätzlich niemals genau auf True prüfen, außer mann will/muß eben wissen, ob es wirklich genau die True-Konstante ist. Ja, ich hab in Boolean auch schonmal absichtlich mehr als nur einen Wert kodiert (ThreeState) oder bei einem Enum oder Set "ungültige" Werte benutzt. :angle2: Und ich kenne viele WinAPIs, die in Delphi falsche implementiert sind. BOOL statt INT und anderesrum. |
AW: TRUE/FALSE Part
Zitat:
EDIT: Hier mal ein Beispiel für eine Datenstruktur mit einem BOOL in der WinAPI: ![]() MfG Dalai |
AW: TRUE/FALSE Part
Aber selbst die "kosmetische Sache" würde mich überzeugen:
Delphi-Quellcode:
ist doch eigentlich eingängig.
if (EtwasZutrifft) then TuEtwas;
Delphi-Quellcode:
ist eher sperrig zu lesen.
if (EtwasZutrifft = WahrIst) then TuEtwas;
Wenn es dann noch Compilerbedingte Gründe für die verkürzte Schreibweise gibt, würde ich mich auf jeden Fall für diese entscheiden. Nachtrag: Mir fiel jetzt noch ein:
Delphi-Quellcode:
würde ja auch niemand schreiben.
if (A = B) = True then ...
|
AW: TRUE/FALSE Part
Zitat:
Delphi-Quellcode:
if APerson.IsMarried then
APerson.DriveHome else APerson.StayWhereYouWant; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz