Über den Umgang mit Boolean

[Tyrael Y.]

Zitat:

Zitat von malo

Also, ich muss ganz ehrlich sagen, dass ich gelegentlich eine Abfrage mit "= false" mache. .....

Ich persönlich finde jedenfalls, dass es übertrieben ist, sich darüber "aufzuregen", dass manche "if irgendwas = true" schreiben. Das Ganze hat auch etwas mit Programmierstil zu tun. Und wer es so übersichtlicher findet, soll es halt übersichtlicher finden. Auf die 6 Zeichen die dabei zusätzlich getippt werden (meinetwegen bei 100 maligem Aufruf 600 Zeichen) kommt es auch nicht mehr drauf an.

Delphi-Quellcode:

if x = false then

ist ja auch richtig
besser
if not(x) then

aber

Delphi-Quellcode:

if x = True

sollte man NIEEEEEEE schreiben....
...dies kann richtig sein, aber muss nicht richtig sein

lies dir das oben bitte nochmal durch, bevor du in Zukunft Fehler im Program hast und die Quell nicht lokalisieren kannst ;)


Gruß

[malo]

Zitat:

Zitat von Tyrael Y.

Delphi-Quellcode:

if x = True

sollte man NIEEEEEEE schreiben....
...dies kann richtig sein, aber muss nicht richtig sein

lies dir das oben bitte nochmal durch

:wall: Jetzt hab ich auch dieses "Problem" verstanden. ;)

Jedenfalls hab ich mir das "= true" schon länger abgewöhnt. Aber das lag hauptsächlich daran, dass ich ziemlich schreibfaul bin :mrgreen:

[Airblader]

Hihi, also zunächst schreibe ich immer "TRUE" und "FALSE" und nicht "true" oder "True", ist für mich einfach signalgebender ;)
Allerdings schreibe ich das nie im if-Statement, um Gottes Willen. Ein Programmierer ist von Natur aus faul und abgesehen davon finde ich "Irgendwas=TRUE" stilistisch einfach schrecklich - so sieht Code doch nicht schön aus ;)

air

[Brüggendiek]

Hallo!

Da war mir in meinem Tut doch tatsächlich der falsche Code reingerutscht - habe ich oben verbessert und markiert :oops: .

Sind ja in kurzer Zeit viele Reaktionen gekommen. Antworten darauf kann ich leider heute nicht mehr schreiben. Zum Einen habe ich im Moment viel zu tun und morgen ist hier in Dortmund Roadshow - da bin ich angemeldet.

Gruß

Dietmar Brüggendiek

[Oxmyx]

Zitat:

Zitat von Airblader

Hihi, also zunächst schreibe ich immer "TRUE" und "FALSE" und nicht "true" oder "True", ist für mich einfach signalgebender ;)
Allerdings schreibe ich das nie im if-Statement, um Gottes Willen. Ein Programmierer ist von Natur aus faul und abgesehen davon finde ich "Irgendwas=TRUE" stilistisch einfach schrecklich - so sieht Code doch nicht schön aus ;)

air

Naja, ein mit C vertrauter Programmierer würde vielleicht meinen, dass du mit TRUE und FALSE die Windows-Konstanten meinst, die als Integer mit 4 Bytes definiert sind.

Zum Tutorial muss ich sagen, dass ich den Schreibstil etwas daneben finde. Es wird dem Leser ständig suggeriert, dass er schwer von Begriff sei.

[negaH]

Zitat:

Der Cast auf Boolean soll doch ein Cast sein, der die Daten nicht verändert, sondern nur den Typ.
Das ist doch gerade der Kernpunkt des ersten Teil des Tutorials!

Würde man deine Konstruktion verwenden, bekäme man in diesem Fall keine Probleme mit einem expliziten Vergleich auf true oder false.

if Boolean = True then
sollte man NIEEEEEEE schreiben....
...dies kann richtig sein, aber muss nicht richtig sein

Ich weis nicht, dein "Tutorial" zieht meiner Meinung nach die falschen Schlußfolgerungen.

Delphi-Quellcode:

if Boolean = True then

Ist zwar eine umständliche Boolsche Auswertung aber immer noch eine korrekte und PASCAL konforme Auswertung die immer richtig umgesetzt wird. Es ist egal ob man dabei den Typen Booelan, WordBool, Bool, ByteBool oder LongBool benutzt.

Das eingentliche Problem mit falschen Auswertung solcher Konstrukte liegt im CAST eines beliebigen Wertes in einen Boolean Datentyp. Robert hat also oben schon absolut die saubere Lösung zur Vermeidung solcher CASTs aufgezeigt.

Denn das nun

Delphi-Quellcode:

if Boolean then
// oder
if not Boolean then

mit casted Datentypen denoch korrekt funktioniert liegt ausschließlich nur an der Art & Weise wie der Compiler diese Abfragen in Maschinencode umsetzt. In diesem speziellen Falle erzeugt nämlich der Compiler keinen direkten Vergleich zweier Datenwerte zueinander sondern benutzt spezielle Features der CPU die immer quasi ein Auschlußverfahren anwenden. Auf Grund dessen ist FALSE als 0 definiert und der Compiler erzeugt einen Code der <> 0 oder == 0 testet, je nach TRUE oder FALSE Bedingung.

Das der Compiler dies so macht ist keine zwangsläufige und dokumentierte Grundlage zur Auswertung Boolscher Bedingungen. Dieses Verhalten ist undokumentiert und man kann sich darauf nicht verlassen !
Der Compiler könnte also interen selber ebenfalls einen direkten Wertvergleich durchführen, dh. also aus

Delphi-Quellcode:

if Boolean then
// macht der Compiler einen Maschinencode wie
if Boolean = Truee then

und würde dann ebenfalls auf die Schnauze fallen mit casted Boolean's.

Die eigentliche Ursache des Problems liegt also nicht in der Art & Weise der Abfrage eines Booleans sondern in der Erzeugung eines Booleans per TypCasts !!

Ergo: Sich hinzustellen und zu behaupten das eine PASCAL konforme Abfrage schlecht wäre und zu Fehlern führt ist die falsche Konsequenz. Dies stimmt nicht, da die Ursache einzigst im Cast eines Datentypes liegt. Man kann zwar versuchen den Schimmelbefall eines Hauses durch einen sauberen Anstrich zu verdecken, aber nur die Beseitigung des Übels schafft wirklich abhilfe. Das macht aber einen schlechteren Hausanstrich nicht verantwortlich dafür das der Schimmelbefall immer noch da ist.

Das die umständliche Abfrage eines Boolschen Datentypes per zusätzlichem Boolschen Vergleich doppelt gemoppelt ist und somit sehr un-clever ist sei unbestritten, aber nicht falsch im Sinne der PASCAL Semantik.

Schaut mal den IT Professoren auf Bayern3 im <IT> Grundkurs zu und was die für schreckliche PASCAL Sourcen als Lehrmittel heranziehen. Da habe ich solche doppeltgemoppelten Boolschen Abfragen schon sehr oft gesehen.

Gruß Hagen

[edit]
Die Frage eines Stils des "Bullet proof" Programmieren kann man aber mit deinem Tutorial sehr wohl begründen. Es ist also sauberer Boolsche Datentypen direkt Boolsch auszuwerten und macht auf Grund der speziellen Auswertung solcher Abfragen durch den Compiler den Code sicherer. Aber er wird dadurch nicht richtiger als die un-celvere Art der Boolschen Abfragen !
[/edit]

[Merlin2001]

Hallo Dietmar,

ich bin Delphi-Anfänger und verstehe folgendes nicht:

Zitat:

Zitat von Brüggendiek

Auswertung boolscher Ausdrücke

(...)
Die verkürzte Auswertung von Boolean-Ausdrücken führt aber zu einer weiteren bösen Falle:

Delphi-Quellcode:

if (Length(StringVar)>=5) and (StringVar[5]='x') then
  IrgendWas;

ist eine ganz gefährliche Sache. Bei optimiertem Boolean wird der 2. Teil nicht mehr ausgewertet; ohne Optimierung jedoch ergibt sich bei AnsiString die Situation, daß der Index außerhalb des Wertebereichs liegen kann.
Solange man in seiner Unit/Komponente den B-Compilerschalter richtig einstellt, sollte beim Austausch von Quellcode nichts passieren. Wenn man sich jedoch auf die Einstellung des Compilers verläßt, ist man verlassen und erhält dann vom Anwender Rückmeldungen, daß das Ganze "manchmal" fehlerhaft läuft.

Du sprichst ja davon, dass bei manchen Abfragen das Ergebnis frühzeitig feststeht.
Wenn ich aber

Delphi-Quellcode:

if (Length(StringVar)>=5) and (StringVar[5]='x') then
  IrgendWas;

schreibe, dann müssen doch auf jeden Fall beide Bedingungen geprüft werden, oder? Schließlich lässt sich aus der Richtigkeit der ersten Bedingung nicht auch das Zutreffen der zweiten schließen (jedenfalls in meiner Logik ^^).
Bitte sei so nett und erklär es mir noch mal etwas genauer ;)

Gruß
Marcus

[Flocke]

Zitat:

Zitat von Merlin2001

Wenn ich aber

Delphi-Quellcode:

if (Length(StringVar)>=5) and (StringVar[5]='x') then
  IrgendWas;

schreibe, dann müssen doch auf jeden Fall beide Bedingungen geprüft werden, oder? Schließlich lässt sich aus der Richtigkeit der ersten Bedingung nicht auch das Zutreffen der zweiten schließen (jedenfalls in meiner Logik ^^).

Wenn die erste Bedingung schon falsch ist (die Länge des Strings also kleiner als 5), dann kann der gesamte Ausdruck nicht mehr wahr werden. Nur dann wird die weitere Auswertung abgebrochen. Das liegt daran, dass "False AND Irgendwas" immer "False" liefert, genau wie "True OR Irgendwas" immer "True".

[stefangeorg]

Servus,

Zitat:

Da hilft

Delphi-Quellcode:

BoolVar:=not (IntVar=5);

Hier würde ich schreiben:

Delphi-Quellcode:

BoolVar:=IntVar<>5;

Was ist denn hier schneller / angebrachter / richtiger?

Grüße,

Georg

[RavenIV]

würdest Du bitte aus dem "Tutorial" ein pdf erstellen, in dem alle Anmerkungen / Korrekturen aus diesem Thread eingeflossen sind?

Danke im Voraus.