The correct answer is that the result is undefined, or unpredictable. It depends on the compiler -- the answer by some compilers may be 5,5,5 because only the last version is stored. Yet other compilers, such as VC++ 2005 Express will give 6,5,5.
Ancient Dragon
Retired & Loving It
30,049 posts since Aug 2005
Reputation Points: 5,662
Solved Threads: 2,343
The correct answer is that the result is undefined, or unpredictable. It depends on the compiler -- the answer by some compilers may be 5,5,5 because only the last version is stored. Yet other compilers, such as VC++ 2005 Express will give 6,5,5.
And others will give you 6, 6, 5 like it should be.
Aia
Nearly a Posting Maven
2,392 posts since Dec 2006
Reputation Points: 2,224
Solved Threads: 218
And others will give you 6, 6, 5 like it should be.
that may be the way we humans think about it, but not compilers.
Ancient Dragon
Retired & Loving It
30,049 posts since Aug 2005
Reputation Points: 5,662
Solved Threads: 2,343
Right to left.
First variable evaluated is the i++. ( i = 5 ) 5 is assigned for the right most %d.
It gets incremented to 6 before is evaluated again. ( i = 6 ).
Next %d gets 6 assigned to it. Not incrementation here.
Last %d gets 6 because the decrement is after being assigned to be printed.
That's how I see it.
6, 6, 5
Aia
Nearly a Posting Maven
2,392 posts since Dec 2006
Reputation Points: 2,224
Solved Threads: 218
My understand in that i++ means the incrementation should be completed after the particular line of code (maybe the printf complicates things). Where ++i means to complete the statement before. So I would have thought the result should be 5, 5, 5 and then i++-- ... which is just 'i=5' before the next line of code.
EDIT: Well this got me curious, GCC gave me 6, 6, 5 as others have suggested.
sillyboy
Practically a Master Poster
686 posts since Mar 2007
Reputation Points: 85
Solved Threads: 64
Only Ancient Dragon has the correct answer. You cannot ++ or -- the same variable in the same statement. The C Standard says doing so is undefined and not guaranteed to give the answer you expect. See this and this .
WaltP
Posting Sage w/ dash of thyme
10,506 posts since May 2006
Reputation Points: 3,348
Solved Threads: 944
> Only Ancient Dragon has the correct answer.
He should have stopped at the end of the first sentence IMO. Attempting to rationalise or explain any apparent results doesn't help.
> in our college we have a repeated C aptitude question... which goes like this
> and the answer given to us was 5,6,5
Find another college, or another tutor. The one you have doesn't have a clue.
No doubt your head is being filled with non-standard / implementation specific mush like how to rationalise UB for your current compiler. You're in for a lot of surprises when you pick up another compiler and find that much of what you've been taught isn't actually usable at all.
Salem
Posting Sage
11,531 posts since Dec 2005
Reputation Points: 5,862
Solved Threads: 953
This is probably just a case of the professor trying to scare kids by using code in a way it generally won't be used. If your professor does insist that is the answer and won't budge, just listen to his explanation and remember his rules for the duration of the course. After you pass the course, you can go back to using code as it should be used.
sillyboy
Practically a Master Poster
686 posts since Mar 2007
Reputation Points: 85
Solved Threads: 64
> 2. The next one is precedence of the operator’s.
Someone else needs to read http://www.c-faq.com/expr/index.html in great detail, to learn about when side effects happen, and what a sequence point is.
Precedence has nothing to do with when side-effects happen.
Given f() * g() + h()
what is sure is that the multiply will happen before the addition, but there is NOTHING which prevents the compiler from calling h() first and storing the result in a register.
Just because your assumptions match what your current compiler seems to do (aka "works for me") is not a valid explanation of how the language (or any other compiler) is going to treat the same code.
Salem
Posting Sage
11,531 posts since Dec 2005
Reputation Points: 5,862
Solved Threads: 953
>hope you are clear..bye...
Please learn C before trying to teach it.
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
> .i think the answer given to you is wrong.
Yes, just as wrong as yours is.
"it was a work of art - flawless, sublime. A triumph equalled only by its monumental failure" - The Architect.
Until you truly understand undefined behaviour (UB), you'll always struggle to come up with increasingly bizarre explanations of what is happening.
Only when you understand what UB really means will you realise that attempts at explaining it are pointless. All such explanations are simultaneously
- right ("works for me, today, with this compiler and this bit of code")
- wrong ("doesn't work for someone else")
- useless ("doesn't help anyone in the long run anyway")
Do the world a favour and read the C.L.C FAQ link I posted a couple of replies ago from end to end, and make sure you really know what UB and "sequence points" are.
Here's something to wrap your noodle around.
#include <stdio.h>
#define MUL(x,y) ((x)*(y))
int mul ( int x, int y ) {
return x * y;
}
int main ( void ) {
int a = 22;
int b = 22;
int r1 = MUL(a++,a++);
int r2 = mul(b++,b++);
printf("%d %d\n", r1, r2 );
return 0;
}
$ gcc -W -Wall -ansi -pedantic foo.c && ./a.exe
484 506
It's the same code apparently, so why the different answers when compiled with gcc?
Salem
Posting Sage
11,531 posts since Dec 2005
Reputation Points: 5,862
Solved Threads: 953
It's the same code apparently, so why the different answers when compiled with gcc?
Because we just entered The Outer Limits ?.
Darn it!. I knew my tax software was cheating me.
Aia
Nearly a Posting Maven
2,392 posts since Dec 2006
Reputation Points: 2,224
Solved Threads: 218