This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Originally posted by Bill Shirley: ...or some cleaner version thereof...
Like i += 2 ?
Note that the behavior of the original code is caused by the assignment combined with the postfix increment. So you could use a prefix increment instead:
i = ++i; i = ++i;
Or even the postfix increment without the assignment:
(Note: You can not use i++++ or even (i++)++, because the postfix operator must be applied to a variable, and it results in a value.)
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Joined: Oct 16, 2007
Actually i know this will print output zero.....i want to know hw it is produced?Thats why i asked the Question?I know that the assignment i=i++; has no effct but would like to know the working flow ...thats why ,Any way i should thank all who replied to my question,i got the answer from the link iven by henry,which was i looking for,so a special thanks to him
It's not the post-increment operator that does the trick. It's not even the lower-precedence-of-assignment-operator. It's the way java executes statements.
I know you didn't get it. When JVM sees a high priority statement is interrupting, it memorizes the current execution, performs the high priority task and then executes the memorized execution.
If you run the above code, you will understand that post-increment operator is not the one playing the trick.
Also, if you print the result returned by the method m() below, you will know that Assignment operator has nothing to do with it as well. Because, a return interrupted by finally also does show this weird behavior.
Well the reason is, the execution goes like this - 1. return statement is memorized first. so all JVM memorizes is 'return 0;' 2. now finally is executed. The variable c's value does change actually. 3. prints updated value of c i.e. 12. 3. memorized task is executed. so, 0 is returned.
Similarly while executing c=(++a/b) in first example, what JVM does is - 1. store c=2/2. 2. increment a. so a = 3, b = 2. 3. execute c=2/2. so c = 1. a = 3, b = 2. 4. print values of a, b & c.
Well, the biggest problem is that, unfortunately, your "different view" is wrong. People are rarely helped by learning a wrong way to think about a problem. There is no such thing as a "high priority task (or instruction)" -- this is something somebody just made up, and it's wrong. If somebody explained things to you this way, you need to go tell them to stop making up nonsense.
As far as the order of execution and exactly what gets stored for later use, it's easy enough to prove that it works the way Rob says by using the "javap" disassembler that comes with the JDK.
int a=2, b=2; int c = a++/b++;
disassembles to the following. I'll add comments on each line in italics to explain:
As you can see, the division and assignment happen after both a and b have been incremented, as Rob says, and in direct contradiction to your stated order. All code on the right hand side of the assignment statement has executed before the assigment is made, including side effects.