Code:main() { int i=4,j=7; j = j || i++ && printf("YOU CAN"); printf("%d %d", i, j); } Answer: 4 1
Actually && has highest priority than ||. But compiler first evaluates || of above program. How is it?
logical operation
Code:main() { int i=4,j=7; j = j || i++ && printf("YOU CAN"); printf("%d %d", i, j); } Answer: 4 1
Actually && has highest priority than ||. But compiler first evaluates || of above program. How is it?
how do you know that it first evaluates || ?Originally Posted by siperi
Grouping of subexpressions and order of evaluation are different, though related, issues.
The (i++ && printf("YOU CAN")) subexpression never gets evaluated because the left hand side, j, with a value of 7, is evaluated as true, and due to lazy/short-circuit evaluation that means that the right hand side of the || is not evaluated.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
using which compiler we will come to know which expression is evaluated first?
I am using Pelles C IDE, is it possible to find this in it?
if yes, how?
thanks
Aside from special cases as in siperi's question, you should just generate assembly output and check what the compiler actually generated.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
In PellesC you can do this by turning off debugging in the Project Options, compile then debut... you will see the assembly code and you can execute it step by step to see what it does.
(Laserlight... One of PellesC's nicer features that nobody seems to know about)
so knowing of assembly language is must ( atleast for this problem ) ?
Read the text of the 1999 edition of the C standard:
Now, "unspecified" means that the behaviour is implementation defined, i.e., it is up to the compiler. Therefore, if you want to know what exactly is the behaviour, then you need to examine what the compiler did, i.e., you need to look at its output. Of course, you might be able to deduce what it did based on say, printf statements, or observing the values in a debugger, but chances are it would not be as clear as looking at assembly output.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
It would help.
Adding a thought to what laserlight has said, keep in mind that "unspecified" also means that unless you are examining this on the same compiler the OP is using, your results may differ.
Not at all.
j=j will ALWAYS be true, and that exits that line of code.
That's the end of it, except to mention that j is now 1.
That would not change, on any C compiler. No assembly examination needed.
If you need to check subexpressions, and what their precedence is, THEN you need further testing and/or examination.
Not at all necessary for this code.
As I stated in post #3, it is not j=j, but just j, which does not necessarily evaluate to true, though it does in this case. The assignment operators have a lower precedence compared to the logical or operator. Consequently, you are correct to say that the value of j will then be 1; if that left hand subexpression was really j=j, then j would still have a value of 7.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Thank you, laserlight - I see what you're saying.
I'm going to have to learn to tilt my head over when I read these weird lines of code.
I generally find it helpful to hold them up to the mirror on my ceiling...Thank you, laserlight - I see what you're saying.
I'm going to have to learn to tilt my head over when I read these weird lines of code.
The short circuit evalation of operators takes effect.
[Edit] nevermind, laserlight's already mentioned it.
Last edited by itCbitC; 11-08-2010 at 10:31 AM.
