Delphi-PRAXiS
Seite 1 von 5  1 23     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   TRUE/FALSE Part (https://www.delphipraxis.net/184484-true-false-part.html)

EWeiss 30. Mär 2015 17:32

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

mkinzler 30. Mär 2015 17:40

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.

Dalai 30. Mär 2015 17:43

AW: TRUE/FALSE Part
 
Detaillierte Erklärung hier: Über den Umgang mit Boolean.

MfG Dalai

BadenPower 30. Mär 2015 17:44

AW: TRUE/FALSE Part
 
Zitat:

Zitat von EWeiss (Beitrag 1295382)
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 ?

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

Wenn Du
Delphi-Quellcode:
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 30. Mär 2015 17:47

AW: TRUE/FALSE Part
 
Zitat:

Zitat von BadenPower (Beitrag 1295389)
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 30. Mär 2015 17:52

AW: TRUE/FALSE Part
 
Zitat:

Zitat von mkinzler (Beitrag 1295386)
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 30. Mär 2015 17:59

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.

Dalai 30. Mär 2015 18:11

AW: TRUE/FALSE Part
 
Zitat:

Zitat von EWeiss (Beitrag 1295391)
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 30. Mär 2015 18:22

AW: TRUE/FALSE Part
 
Aber selbst die "kosmetische Sache" würde mich überzeugen:

Delphi-Quellcode:
if (EtwasZutrifft) then TuEtwas;
ist doch eigentlich eingängig.
Delphi-Quellcode:
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:
Delphi-Quellcode:
if (A = B) = True then ...
würde ja auch niemand schreiben.

Sir Rufo 30. Mär 2015 18:27

AW: TRUE/FALSE Part
 
Zitat:

Zitat von stahli (Beitrag 1295405)
Aber selbst die "kosmetische Sache" würde mich überzeugen:

Delphi-Quellcode:
if (EtwasZutrifft) then TuEtwas;
ist doch eigentlich eingängig.
Delphi-Quellcode:
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;


Alle Zeitangaben in WEZ +1. Es ist jetzt 18:09 Uhr.
Seite 1 von 5  1 23     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz