TRUE/FALSE Part

[EWeiss]

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?

If Foo = True then
if Foo then


If Foo = False then
if not Foo then

Was macht jetzt den Unterschied ?

gruss

[mkinzler]

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.

[Dalai]

Detaillierte Erklärung hier: Über den Umgang mit Boolean.

MfG Dalai

[BadenPower]

Zitat von EWeiss:

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?

If Foo = True then if Foo then
If Foo = False then if not Foo then Was macht jetzt den Unterschied ?

Wenn Du auf If Foo = True then prüfst, dann prüft Du, ob Foo den Booleanwert TRUE hat.

Wenn Du If Foo then auswertest, dann prüft Du, ob die Auswertung von Foo "Wahr" ergibt.


Und tunlichst darauf verzichten halte ich für falsch, denn es gibt Situationen, in denen man direkt auf TRUE prüfen muss.

[Der schöne Günther]

Zitat von BadenPower:

Und tunlichst darauf verzichten halte ich für falsch, denn es gibt Situationen, in denen man direkt auf TRUE prüfen muss.

Elaborieren Sie.

[EWeiss]

Zitat von mkinzler:

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.

Nun mir erschließt sich das immer noch nicht.
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

[himitsu]

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.

Und ich kenne viele WinAPIs, die in Delphi falsche implementiert sind.
BOOL statt INT und anderesrum.

[Dalai]

Zitat von EWeiss:

Doch kosmetische Sache?

Nein. Sobald du eine API-Funktion direkt aufrufst, die z.B. einen BOOL zurückgibt (oder einen solchen Typ als out-Parameter hat), entspricht das Ergebnis eben nicht mehr zwingend einem Boolean. Dazu muss man noch nicht einmal irgendeine DLL laden, denn auch kernel32.dll, shell32.dll usw. reichen da bereits aus.

EDIT: Hier mal ein Beispiel für eine Datenstruktur mit einem BOOL in der WinAPI: http://blog.delphi-jedi.net/2008/09/...n-and-integer/

MfG Dalai

[stahli]

Aber selbst die "kosmetische Sache" würde mich überzeugen:

if (EtwasZutrifft) then TuEtwas; ist doch eigentlich eingängig.
if (EtwasZutrifft = WahrIst) then TuEtwas; ist eher sperrig zu lesen.

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: if (A = B) = True then ... würde ja auch niemand schreiben.

[Sir Rufo]

Zitat von stahli:

Aber selbst die "kosmetische Sache" würde mich überzeugen:

if (EtwasZutrifft) then TuEtwas; ist doch eigentlich eingängig.
if (EtwasZutrifft = WahrIst) then TuEtwas; ist eher sperrig zu lesen.

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.

Mit englischen Begriffen liest es sich sogar fast wie Prosa

Delphi-Quellcode:

if APerson.IsMarried then
  APerson.DriveHome
else
  APerson.StayWhereYouWant;