prints 56. That makes sense to me, because it has to unbox m to apply the postfix operator, so by the time the multiplication is done the first m and the second m are no longer the same object. One contains and 8, the other a 7. Maybe my understanding is wrong, but anyway the result is the one I expected.
But I don't understand why this code
also prints 56. I expected it to print 64. It behaves as if the first m -- the one in m++ -- is a local variable separate from the second m. That is, it looks like the values of each primitive are evaluated, then the postfix is applied to one of these values, and then the multiplication is done.
What is happening in the second example that makes it print 56? Is m, the local variable in pinch(), affected at all by this operation?
Costs matter. Justice lies in processes not outcomes. Crime is caused by criminals.
Difficult to be sure about the first instance; you are passing an Integer object; as you know, Java is pass-by-value, so the method cannot change the value of the origin of its parameters. It probably unboxes the Integer (7) to an int and increments it to 8; whether it is boxed again I don't know. That might actually be a meaningless question.
You will remember that the ++ operator increases m, but the expression m++ returns the old value, 7. Then when you get to the other m it has the value 8. Remember that Java always works from left to right, and that the postfix operator has a higher precedence than any other arithmetic operator. So you are calculating 7 * 8 (56), not 8 * 7.
In the 2nd example, it is easier to understand.
You pass 7, increment it to 8 and return the old value, again calculating 7 * 8 and getting 56. The problem is that the expression m++ returns 7 when the value of m is 8.
Remember post-increment expressions return the old value, and pre-increment expressions return the new value.
Joined: Oct 13, 2005
When I said "meaningless," I meant that it is of no importance whether the JVM boxes the 8 into an Integer, or keeps it as an int until after the end of the arithmetic. Also, since there is no further call to the Integer object after the multiplication, it might let the value vanish into cyber-limbo (or fall off the stack) because there is no need for it again. Remember the JVM is programmed to optimise code at runtime, and that would count as an optimisation.
Joined: Jan 20, 2008
Remember post-increment expressions return the old value, and pre-increment expressions return the new value.[/QB]
Oh... OK... So m does get modified but the postfix operator does a bait-and-switch type thing, returning the old value, in order that the operator is seen to be applied after the expression it is part of, is that it? So there must a be a temporary variable in there.
Exactly! If you look at the generated byte code (for example by using javap), you will see that the post-increment operator really works in three steps:
- remember the old value (in kind of a temporary variable) - increment the original value - use the old value for further calculations
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Can you refresh my memory on where the bytecode is stored? I'm using javac.
Joined: Oct 13, 2005
The bytecode is the contents of the .class files created from javac. You can use the javap tool or a hexadecimal editor to view that; there is a list of what each byte means somewhere in the Java Virtual Machine Specification.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com