Timer Steuern
-
Martin Richter schrieb:
Deshalb sollte man eine BOOL Variable nicht mit TRUE vergleichen!
Womit dann?
bool (kleingeschrieben) kann dagegen wirklich nur die Werte true (1) und false(0) (kleingeschrieben annehmen).
Ich verwende wo es geht nur bool!
Genau, aber sobald man eine GUI dabei hat, wird es bunt gemischt.
-
[quote="estartu"]
Martin Richter schrieb:
Deshalb sollte man eine BOOL Variable nicht mit TRUE vergleichen!
Womit dann?
[quote="estartu"]Meistens kann man sich einen Vergleich sparen. In einem if und while genügt es einfach die Variable zu schreiben ohne == oder !=.
Ansonsten ist nur der Vergleich zu FALSE sicher.
BOOL bMyState = 56; // Das geht! if (bMyState) // OK ... if (!bMyState) // OK ... if (bMyState==FALSE) // OK ... if (bMyState!=FALSE) // OK ... if (bMyState==TRUE) // FAAAAALSCH!!!!!! ... if (bMyState!=TRUE) // FAAAAALSCH!!!!!! ...Ich verwendenur die Varianten 1 und 2!
Ein BOOL wir durch den Vergleich !=0 (!=FALSE) korrekt in einen bool gewandelt.bool (kleingeschrieben) kann dagegen wirklich nur die Werte true (1) und false(0) (kleingeschrieben annehmen).
Ich verwende wo es geht nur bool!
Genau, aber sobald man eine GUI dabei hat, wird es bunt gemischt.
Aber das stört doch keinen. ein bool kann immer für ein BOOL herhalten!
Also bervorzuge ich grundsätzlich bool. Sag mir mal wo Du BOOL wirklich brauchst?
-
Kannst du das mit dem TRUE begründen?
Ich vergleiche tendenziell eher mit TRUE und habe noch keine direkten Nebenwirkungen bemerkt.Alleine für die Wandlung BOOL nach bool mache ich das unzählige Male.
-
estartu schrieb:
Kannst du das mit dem TRUE begründen?
Ich vergleiche tendenziell eher mit TRUE und habe noch keine direkten Nebenwirkungen bemerkt.Vergelichst Du Variant-Bolls auch mit TRUE!? Dann machst Du aber was falsch... denn dort gibt es "VARIANT_TRUE"
FALSE ist eigentlich immer "0"! TRUE kann sich je nach (ungeschicktem) Define entweder 1 oder -1 sein...
Deswegen: Immer mit "FALSE" vergleichen und *nie* mit "TRUE"!
-
estartu schrieb:
Kannst du das mit dem TRUE begründen?
Ich vergleiche tendenziell eher mit TRUE und habe noch keine direkten Nebenwirkungen bemerkt.Alleine für die Wandlung BOOL nach bool mache ich das unzählige Male.
Horror!
Mein Beispiel, warum man es nie machen sollte:
BOOL bValue = 56; // Legaler Code und kann ein legaler return // wert einer SDK Funktion sein (dort steht nur !=0 bei success z.B.) // boolValue ist nun false bool boolValue = bValue==TRUE;
-
Okay, also ich verwende es eigentlich nur im Zusammenhang mit Checkboxen.
Da sollte es ja nicht so schlimm sein.Martin Richter schrieb:
Mein Beispiel, warum man es nie machen sollte:
BOOL bValue = 56; // Legaler Code und kann ein legaler return // wert einer SDK Funktion sein (dort steht nur !=0 bei success z.B.) // boolValue ist nun false bool boolValue = bValue==TRUE;Okay, wenn da "!=0 bei success" steht dann vergleiche ich auch auf 0.
-
estartu schrieb:
Okay, also ich verwende es eigentlich nur im Zusammenhang mit Checkboxen.
Da sollte es ja nicht so schlimm sein.Was prüfst Du da? Den Status?
Nur als Anmerkung: Auch hier sollte man vorsichtig sein. Eine Tristate-Checkbox kennt 0,1,2 und da 2!=TRUE ist, liegt hier mindestens auch solch ein Problem.
Du baust also die UI um und schon wirds lustig...
Man sollte ==TRUE niemals nicht und überhaupt nicht verwenden!
-
Hmm, viel zu viele Fallen für einen eigentlich so einfach scheinenden Datentyp.
-
estartu schrieb:
Hmm, viel zu viele Fallen für einen eigentlich so einfach scheinenden Datentyp.
Die Falle ist immer der == Operator!
-
Martin Richter schrieb:
Man sollte ==TRUE niemals nicht und überhaupt nicht verwenden!
ACK!
