:cuss:first code segment: Code: #include<iostream.h> #include<conio.h> main() { int a=1; clrscr(); int b=a+a++ +a++ +a++ ; cout<<b<<a; getch(); } :cuss:second code segment: Code: #include<iostream.h> #include<conio.h> main() { int a=1; clrscr(); int b=a+a+a++ +a++ +a++ ; cout<<b<<a; getch(); }
You have undefined behaviour because you are using modifiers on the same variable more than once in the same statement. Basically it's up to the compiler writer how they implement this. If a=5 then a++ + a++ could be: (1) 5 postincremented to 6, plus 6 postincremented to 7, which is 11 (5+6); (2) 5+5 then a postincremented twice, which is 10 (5+5) Both are equally valid according to the Standard. That said I can't see how the same result is achieved for both programs. Postincrements saved to the end 1+1+1+1=4 1+1+1+1+1=5 Postincrements done inline L->R 1+1+2+3=7 1+1+1+2+3=8 Postincrements done inline R->L 1+2+3+4=10 1+2+3+4+4=13 It would have helped enormously if either of you could have said (a) what the compiler is and (b) what the results were. I only have Visual Studio 2010, which I know from past experience saves postincrements to the end and the results would have been 4 and 5. To find out why you get the same result for both programs you will have to compile to assembly (most compilers will do this) then inspect the resulting assembly code. That will show you how the result is achieved.
I got the same result as xpi0ti0s mentioned. Compiler used : gcc 4.1.1 The compiler postincrements to the end
I've had a good think about this and I REALLY can't see how you get the same result for both programs. Shabbir, the difference is that the second program has an extra a in it, so the first program adds 4 a's, and the second adds 5 a's, both with three post increments. Actually I suspect it's down to something else like you haven't compiled the second program. OP, my suggestion is to modify the first program to: Code: cout<<"Test 1: "<<b<<a; and the second to: Code: cout<<"Test 2: "<<b<<a; Then post the exact results (use copy and paste if you don't want to type it in) and maybe I'll be able to guess how it got to the results. As the results for different order of evaluation don't have any overlap it can't be that you're using different compiler flags to affect the order of evaluation, so if you really are getting the same results then either you're doing something daft or you have a compiler bug (which is possible; clrscr and getch suggest you're using Turbo C 3.0, which seems very popular on this site for no obvious reason, and is very old and has numerous bugs, so the bottom line could be that you need a newer compiler).
#include<iostream.h> #include<conio.h> main() { int a=1; clrscr(); int b=a+a++ +a++ +a++ ; cout<<b<<a; getch(); } output is 8 #include<iostream.h> #include<conio.h> main() { int a=1; clrscr(); int b=a+a+a++ +a++ +a++ ; cout<<b<<a; getch(); } here one more 'a' is added to the statement. result is 8 this time also compiler is TC
The output cannot possibly be "8" because of Code: cout << b << a; That means you will get 2 numbers, not one. As I said in my previous post, modify the programs to include Test1 and Test2, then post the EXACT output from BOTH programs. Look the word EXACT up in the dictionary if you're not sure. Basically what it means is that if the output of the program is "Test1 3764" then I want you to post "Test1 3764" (and of course the Test2 output).
sir, result for cout<<b is 8 in both the cases. i had written cout<<b<<a; just to see what value 'a' is holding. problem is with b=a+a++ +a++ +a++; is giving output 8 when a=1 and second part b=a+a+a++ +a++ +a++ is giving output 8. in the second statement there is five a whree as in first only four.
exactly , i am getting two numbers, but issue is with cout<<b where i am getting output 8 with 4 a's and 5 a's. in both the cases i am having three a++.
No idea. If you won't give me the info I ask for then I can't help. Compile to assembly if you want to see what's going on. I tried installing TC3 but no chance on 64-bit Windows 7 - the installer won't even start. The bottom line is going to be either (a) undefined behaviour as previously explained, or (b) a bug. Due to the UB there is no "correct" result for either of the expressions so this is purely speculative anyway.