Missing '=' in if-statement
-
Does the expression
myBool = falsethe valuetrue? :wtf: It's been a long time since I touched any Java, but that can't be true. That would be totally f-ed up!-- Mit viel Oktan und frei von Blei, eine Kraftstoff wie Benziiiiiiin!
-
Missing '=' in if-statement : if (myBool = false) // This if-statement will now always return 'true'. System.out.println("This line will now ALWAYS be executed !"); The correct syntax is, of course : if (myBool == false)
As someone who uses the Digital Mars C++ compiler (formerly Symantec C++ and before that Zortech or the like) I never get this problem as the compiler always warns of an unintended assignment. If you *do* intend to do an assignement then you need to code: if ((flag=value)==TRUE) ... or similar. I.e. the compiler makes you be explicit about what you're writing.
-
Yes, it just sets the value of 'myBool' to False and after that, the complete statement is evaluated as true.
Oh no. At least in C/C++ the result of the assignment is the right-most value, i.e. false. Similarly,
if (i=2) {...evaluates to 2.Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
-
Oh no. At least in C/C++ the result of the assignment is the right-most value, i.e. false. Similarly,
if (i=2) {...evaluates to 2.Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
My point is, the conditions 'myBool = false' and 'i=2' are both 'seen' as 'true' as far as the if-statement is concerned. In other words : if (myBool = false) { // This line will always be executed. } if (i = 2) { // This line will always be executed, even if i <> 2. // And, in fact, i will now be 2. }
-
My point is, the conditions 'myBool = false' and 'i=2' are both 'seen' as 'true' as far as the if-statement is concerned. In other words : if (myBool = false) { // This line will always be executed. } if (i = 2) { // This line will always be executed, even if i <> 2. // And, in fact, i will now be 2. }
I understand your point, but I still think you are wrong (at least in C/C++) if (myBool = false) { // this line will never ever be executed, as the statement evaluates to false } if (i = 2) { // this line will always be executed, because the statement will evaluate to 2, which is non-zero and thus true. } if (i = 0) { // this line will not be executed, the statement evaluates to 0 => false } (disclaimer: I'm not on my devel PC right now, so this is from memory. But I'm pretty sure...)
Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
-
I understand your point, but I still think you are wrong (at least in C/C++) if (myBool = false) { // this line will never ever be executed, as the statement evaluates to false } if (i = 2) { // this line will always be executed, because the statement will evaluate to 2, which is non-zero and thus true. } if (i = 0) { // this line will not be executed, the statement evaluates to 0 => false } (disclaimer: I'm not on my devel PC right now, so this is from memory. But I'm pretty sure...)
Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
-
No, 'i = 2' doesn't evaluate to 2, because this is not a valid comparison-statement (comparison-statements use '=='). So 'i = 2' is actually an an ASSIGNMENT and the if-statement seems to evaluate assignments to 'true', at least in Java.
I guess it's different between C/C++ and java. I will check it in C/C++ (just for the sake of completeness :)) tonight. Untill then, we agree that i = 2 is an assignment, but I'm pretty sure that in C++ this will evaluate to the right-most element, i.e. 2. And 2 is a true value in C/C++. The evaluate-to-rightmost rule also works here:
int i = j = 2;here 2 is assigned to j, and the result of this assignment (i.e. 2) is assigned to i. Anyway, thanks for the discussion!Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
-
pragma codeproject wrote:
wish VS had a compiler warning about "=" in ifs like the codewarrior compiler had
It does :confused:
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
tell me where and you'll save my day :) honest, I didn't find it. I usually use warning level on 3, can't go to 4 since a lot of other code (cross platform) creates noise then. R
-
pragma codeproject wrote:
IMHO using = in the if-clause is bad style anyway.
Yeh, I agree with that completely.
When I am king, you will be first against the wall.
Well, I don't. ;-) I code PHP, and I use that pretty often, ie. if ($file_handle = fopen("filename", "r")) { // do something } else { die("File cannot be opened!"); } That part above returns handle if opened (and that resolves TRUE when it's passed into the variable), and an error otherwise (which resolves FALSE). ...I guess You're going to smack me down for using the last for() element for computation, leaving empty {} brackets, too? :P
-
No, 'i = 2' doesn't evaluate to 2, because this is not a valid comparison-statement (comparison-statements use '=='). So 'i = 2' is actually an an ASSIGNMENT and the if-statement seems to evaluate assignments to 'true', at least in Java.
"So 'i = 2' is actually an an ASSIGNMENT and the if-statement seems to evaluate assignments to 'true', at least in Java." in C also, in C++ also, in PHP also etc. The only language I know of where it DOESN'T evaluate ASSIGNMENTS to TRUE is PASCAL (what with assignment operator being := and all...)
-
As someone who uses the Digital Mars C++ compiler (formerly Symantec C++ and before that Zortech or the like) I never get this problem as the compiler always warns of an unintended assignment. If you *do* intend to do an assignement then you need to code: if ((flag=value)==TRUE) ... or similar. I.e. the compiler makes you be explicit about what you're writing.
"if ((flag=value)==TRUE) ... " Now THIS could be adopted as a 'good practice' over that crappy "value == variable" thing! The latter won't work, for example, when You by mistake do something like if (variable_a = variable_b) { ... and since the names can be pretty long (no limits, really), it'd be tough to spot. With the former approach, one'd see the above as NOT being right, not being: if ((variable_a = variable_b) == TRUE) { ... Could be useful. Thanks :) On a side note, I like to do "if (variable_a === variable_b)", so that I can ommit one "=" and still get away with it (I like to be explicit about what I expect to get exactly, especialy with OOP which in itself obfuscates the code in its own way...)
-
"So 'i = 2' is actually an an ASSIGNMENT and the if-statement seems to evaluate assignments to 'true', at least in Java." in C also, in C++ also, in PHP also etc. The only language I know of where it DOESN'T evaluate ASSIGNMENTS to TRUE is PASCAL (what with assignment operator being := and all...)
-
beg to differ, but C and C++ do not evaluate assignments to true. They evaluate to the rvalue. And yes, I just tried it using GCC.
#include int x; int main() { if (x=0) { printf("assignments evaluate to true!\n"); } return 0; }I stand corrected. :-)
-
A way to avaoid this pitfall is use if (false == bool)...the compiler will flag up an error if you use "=" instead of "==".
Thanks!!! Never thought about that one!! It make sense and prevent us to do stupid logical error in a if statement. Now, I just have to remember to code like this.
Progamming looks like taking drugs... I think I did an overdose. ;-P
-
tell me where and you'll save my day :) honest, I didn't find it. I usually use warning level on 3, can't go to 4 since a lot of other code (cross platform) creates noise then. R
Warning level 4...
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
"if ((flag=value)==TRUE) ... " Now THIS could be adopted as a 'good practice' over that crappy "value == variable" thing! The latter won't work, for example, when You by mistake do something like if (variable_a = variable_b) { ... and since the names can be pretty long (no limits, really), it'd be tough to spot. With the former approach, one'd see the above as NOT being right, not being: if ((variable_a = variable_b) == TRUE) { ... Could be useful. Thanks :) On a side note, I like to do "if (variable_a === variable_b)", so that I can ommit one "=" and still get away with it (I like to be explicit about what I expect to get exactly, especialy with OOP which in itself obfuscates the code in its own way...)
It's one of the nicer things about the DM compiler (though it's looking very long in the tooth nowadays). I just wish all the compiler vendors (MS VC++, Intel, et al) would all look at each other and port the best bits. I still cannot believe that MS C++ has no support for the ubquitous (but non-standard) 0b010101 binary format (or %b in it's printf() function). Interestingly, I once had cause to use some Microsoft supplied headers (MFC or Windows Platform API, can't remember which) but the DM compiler found several such mistakes in the headers. I duly reported them to MS and felt quite smug ;-) Paul
-
tell me where and you'll save my day :) honest, I didn't find it. I usually use warning level on 3, can't go to 4 since a lot of other code (cross platform) creates noise then. R
-
you can change the level for specific warnings using a pragma: #pragma warning( 3 : 4706 ) This will change the level of warning 4706 to 3 so that it will report: warning C4706: assignment within conditional expression when the warning level is 3.
cool, thanks!