Missing '=' in if-statement
-
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!