• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

A postfix question

 
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This code



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?
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Thomas Kennedy
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

So this



prints

8
42
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Thomas Kennedy:

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
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Campbell Ritchie:
It probably unboxes the Integer (7) to an int and increments it to 8; whether it is boxed again I don't know.


Yes it is. i++ is short for the following:

The following prints 5:
 
Thomas Kennedy
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can you refresh my memory on where the bytecode is stored? I'm using javac.
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic