c programming
hello alll...
can someone please explain me the output of the following.. Code:
#include <stdio.h> |
It's called "short circuit evaluation". C *stops* evaluating an expression with "&&" or "||" as soon as it has a definite true/false answer:
Code:
#include <stdio.h> http://en.wikipedia.org/wiki/Short-circuit_evaluation 'Hope that helps |
in your if statement you are not comparing(i.e a==1), you are actually testing the success of the assignment functions mapped to the operators =, and += respectively. As a result, unless something is wrong with your ram, they will always *return* true, but will actually assign those values to a,b,and c, causing the output to be always be displayed as "a=0 b=4 c=4".
|
Quote:
Kevin Barry |
Okay, just to be completely pedantic, it isn't a 'return' value (which is reserved for functions), but simply the evaluation of an expression. The value of an assignment expression is the value assigned to the lvalue on the left hand side of the assignment operator.
What mf93 said is just not even close to any part of the C language. The OP's sample code looks like homework, and paulsm4 has correctly seized on the essence of the question. --- rod. |
MF93 pointed out that this is one of the most notorious pitfalls of C. C does not distinguish a boolean type. In C, any nonzero integer is true. Using assignment operator "=" instead of comparison operator "==" as a logic parameter in a conditional expression will always be true unless the assigned value is zero. This can cause hidden bugs which pass program testing and are detected after the program is delivered to the end user. The compiler can generate warnings for this syntax. Setting all warnings as errors in the compiler and editing the source code to clear all warnings can prevent this bug.
|
This "pitfall" is also a very powerful technique. There are perfectly legitimate reasons to WANT to a) do an assignment, b) treat the result as a boolean, and perhaps even c) string several of these expressions together.
The lesson to be learned isn't to AVOID it. But rather, to UNDERSTAND it. And, of course, to exploit this feature whenever/wherever applicable :) PS: What mf93 said is flat-out wrong. |
Quote:
--- rod |
Quote:
Quote:
Code:
a = b = c = 4; /*<-- this sets all three to '4'*/ |
I'll chime-in with a politely dissenting opinion, if I may.
I've spent most of my ~30 year career as a consultant in the literal sense of the word. It's not quite that "I pick up the pieces where other programmers and projects have screwed-up things royally," but, well, it is pretty-damm close to that. And so I have seen a lot of "clever" code like that, and I have rewritten a lot of it. A favorite saying is, "at 3 billion ops a second, no one can hear you scream." CPUs today are unbelievably fast ... but there is also a subtle and therefore often-overlooked reason why they are so fast: the compiler. Processors like the x86 have highly "pipelined" architectures and lots of very-strange instructions. Intel and AMD work hand-in-hand with compiler writers (and publish their own compilers) specifically so that code will be generated, and generated "in the right way," to fully exploit the architecture ... which is designed to be fully-exploited by code that has been generated "in the right way." So, here's my simple advice: don't be clever ... don't even try anymore. Especially if the compiler is issuing a warning or informational message, pay attention to that message and do whatever you have to do to make that message go away. Your code should compile clean: no errors, no warnings, no hints. And of course there is another, even more compelling reason: code that is "clever," that therefore cannot be "instantly and accurately read and understood by a distracted human being at first glance," is absurdly expensive. Sure, it might over the course of your entire lifetime save as much as one tenth of one second of actual wall-time, but the cost of a bug or the cost of difficulty in maintenance is beyond calculation. Thousands of dollars. Millions. No kidding. Make your code "stupid-easy to read." :tisk: Your compiler will thank you (and will work magic on your behalf). Your colleagues, employers, and customers will thank you even more. |
thankyou so much to all of you.. it was indeed very helpful.
|
WARNING: THIS POST HAS BEEN WRITTEN BY SOMEWHAT OF A C N00B :p
I've found that evaluating the "success" or "failure" of an assignment operation (i.e. zero or non-zero assignment) can be useful in checking the return value of a function that returns NULL on error: Code:
SDL_Surface* disp = NULL; |
I find MrCode's code perfectly readable, and fully acceptable C idiom. Modern compilers and sundialsvcs seem to differ.
I would differ on the use of terms such as success/failure to describe the assignment. The assignment always succeeds, or the computer is broken. The assignment constitutes an expression, which, depending on the context, evaluates to a boolean. The 'success/failure' aspect may be a condition of the function call, again depending on context. --- rod. |
Quote:
|
@MTK
I think the argument sundialsvcs is trying to make is that expressions like the one in my example code above aren't "stupid simple to read" and should thus be avoided, and preferably replaced with something like this: Code:
SDL_Surface* disp = NULL; Code:
void strcpy(char* s,char* t) { while(*s++ = *t++); } |
Quote:
Code:
if ( (disp = SDL_SetVideoMode(1,1,BPP,SDL_SWSURFACE | SDL_DOUBLEBUF)) == NULL ) I'm all for 'stupid-easy'. :) |
Quote:
Code:
if ( NULL == (disp = SDL_SetVideoMode(1,1,BPP,SDL_SWSURFACE | SDL_DOUBLEBUF)) ) Kevin Barry |
I know this thread has been marked [SOLVED] and is starting to age quickly (:p), but another thing comes to mind: I've seen some code where an if statement is used to check for the "existence" (i.e. non-zero value of) a variable like this:
Code:
int someVar = SomeIntReturner(); |
Quote:
I can see why putting the NULL first would make it more readable, especially for functions with many parameters that might go over multiple lines. Think I'll start doing that myself. :) |
Quote:
|
Ahh, I see. Thanks MrCode. :)
And yes, I appreciate that they're logically the same. I guess I just prefer an explicit comparison to NULL to the use of the negation operator, as a matter of style. YMMV. |
I also, usually prefer "== NULL" over the negation operator, but not necessarily because it's more explicit, but because the tiny exclamation mark seems like it can easily be missed if you're quickly looking over the code. When I use it, I prefer to put as space after it to make it stand out:
Code:
if (! someFunction()) { |
Quote:
--- rod. |
All times are GMT -5. The time now is 11:17 AM. |