Rückgabewert beim Aufruf von WinAPI-Funktionen testen
-
TRUE ist aber 1 und nicht "jede Zahl ungelich 0". Das heißt, wenn du
myvar == TRUE testest, ist das nur Wahr, wenn myvar == 1 ist und nicht, wenn myvar einen wahren Wert hat (also ungleich 0).
Beispiel:
int i = 5; if (i) { // wird ausgeführt, da i ungleich 0 // hier wird also geprüft, ob i ungleich 0 ist und nicht ob es 1 ist } // aber: if (i == TRUE) { // wird nicht ausgeführt, da 5 ungleich 1 } // und if (i == true) { // wird ausgeführt (wahrscheinlich mit Compilerwarnung) // da i erst auf bool gecastet wird und dann mit true verglichen }[ Dieser Beitrag wurde am 18.02.2003 um 16:40 Uhr von Loggy editiert. ]
-
a) man vergleicht nie einen boolschen Wert explizit mit true oder false
b) beiint i = 42; if (i == true) ...wird true in int umgewandelt, nicht i in bool; deshalb ist der Vergleich ebenfalls falsch.
-
Wird da jetzt eigentlich immer der "kleinere" Datentyp für den Vergleich in den größeren umgewandelt, oder immer der rechte in den linken? Kurz: wäre ein Vergleich if (true == i) wahr?
-
immer der kleinere in den größeren und signed in unsigned, unabhängig von der Reihenfolge. Die Regeln stehn detailliert im entsprechenden Standard, aber es läuft auf die einfache Formel hinaus.
-
a) man vergleicht nie einen boolschen Wert explizit mit true oder false
Das verstehe ich nicht. Wieso sollte man folgendes nicht machen:
bool b = true; if (b == true) { // do... }
-
das wäre doch nur ein unnötiger (meist nicht erfolderlicher), zusätzlicher Vergleich
-
Loggy: Warum sollte man? Eine Bedingung gilt als wahr, wenn sie in bool umgewandelt true ist, dh
if (b)
ist äquivalent
if (b == true)
ist äquivalent
if ((b == true) == true)
ist äquivalent
if (((b == true) == true) == true)
.. you get the idea
-
Und bei BOOL also int? Wie sollte man es da machen?
-
BOOL b = some_predicate();
if (b) ... da BOOL automatisch nach bool umgewandelt wird (0 -> false, alles andere -> true)
(hier ist wie schon gesagt if (b == TRUE) oder if (b == true) nicht äquivalent)
-
Ne, man muss es natürlich nicht (ich mache es wahrscheinlich auch nie), aber manchmal ist es vielleicht aufgrund der Lesbarkeit besser...
Ansonsten hast du natürlich recht.
-
Original erstellt von Bashar:
**Loggy: Warum sollte man? Eine Bedingung gilt als wahr, wenn sie in bool umgewandelt true ist, dhif (b)
ist äquivalent
if (b == true)
**Falsch! Beispiel:
BOOL b; int* pi = (int*)&b; *pi = 23; // ;) if(b) printf("b != 0"); if(b == TRUE) printf("b == TRUE");
-
was soll mir das jetzt sagen? Ich redete von bool, nicht von BOOL.
-
hä?? Natürlich hat Bashar recht.
-
Original erstellt von Bashar:
was soll mir das jetzt sagen? Ich redete von bool, nicht von BOOL.Ist das Gleiche. Meinetwegen ersetze in obigem Code BOOL durch bool.
-
OK, ich habs mir mal angesehen. Ich tipp auf UB, bin mir aber nicht ganz sicher, da ich die Stelle im Standard nicht finde. GCC übersetzt den Vergleich mit true jedenfalls mit "cmpb $1, -1(%ebp)". Das heißt, die Autoren von GCC gehen davon aus, dass eine bool-Variable niemals einen anderen Wert als 0 oder 1 haben kann. Normalerweise macht man solche Annahmen aber nur, wenn der Standard das so definiert, bzw. jede Operation, die das verletzen könnte, als UB bezeichnet.
Sollte es wieder erwarten kein UB sein, hast du Recht, ansonsten ist dein Snippet kein C++
-
Keine Ahnung, was du da faselst.
Aber mein Compiler (BCB 3) nimmt den Code ohne zu murren an. Im Übrigen ist es genau das, was ich am Anfang auch nicht geglaubt habe. Loggy hat mich da eben eines Besseren belehrt.
-
Es geht um Undefined Behaviour, nicht darum was irgendein Compiler annimmt oder nicht.
-
Ahh... UB == Undefined Behaviour == Undefiniertes Verhalten. Na, das muss einem doch erstmal gesagt werden.
-
Oops, ich hätte es wohl wenigstens einmal ausschreiben sollen