Don't let it worry you. Everybody else gets confused, too.
Pablo Napoli wrote:. . . i'm very confused with this.
Afraid that is incorrect. The increased value is indeed stored in i immediately, but the whole expression i++ has the old value of i. Then the assignment (=) overwrites the new value of i with the old value.
I know that i++ change the value of i the next time thatit is used (unlike ++i). But i don't know why first it does not increase the value of the variable and then store it in "i". . . .
this means: i=i++ says in words: read the current value of i (0), then update i (this is whats called an atomic process) (new value: +1), and now final store the read value of 0 back to i
so, i, wich is atomic increment gets overridden by the previous read value - and hence is always 0
Are you sure about that? Is that what it says in the Java® Language Specification (=JLS)? Look here. It doesn't say anything about order of execution, but says that the value of the whole expression is equal to the old value of the variable. I always look on it as meaning there are two values, the value of i and that of the whole expression i++.
Matt Wong wrote:well, the reason is the order of execution with post-increment . . .
How do you know that x++ is atomic? I couldn't find anything in the JLS about ++ being atomic.
. . . this is whats called an atomic process. . .
Campbell Ritchie wrote:How do you know that x++ is atomic? I couldn't find anything in the JLS about ++ being atomic.
Tim Holloway wrote:But, percolating back up to the Java source level, I'm pretty sure you're safe in considering pre- and post- increment/decrement subexpressions as "atomic", in the practical sense, if not in the formal sense for a single variable operand.
Think of how stupid the average person is. And how half of them are stupider than that. But who reads this tiny ad?
Java file APIs (DOC, XLS, PDF, and many more)https://products.aspose.com/total/java