Timer Steuern
-
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!
