Q about increment and assignment

[Patricia Shanahan]

I'm confused by the output of the following code:

public class PP {
public static void main(String[] args) {
int i = 1;
i = i++;
System.out.println(i);
}
}

It outputs 1.

I understand the assignment operator happening before the ++,
but I don't understand why the ++ doesn't increment. I thought
the statement should basically expand to:

i = i;
i = i+1;

but the ++ gets lots somewhere...

No, it gets expanded into:

t = i;

John, is t a copy of the bits in i made by the postfix ++ method?

The sample code is a Java equivalent to the original statement.

Is it fair then to say that t gets restored because of the way the
postfix operator applies only after the expression is evaluated?

What is the difference between the original problem and this one?

int i=1;
System.out.println("i=" + i++); //output=1
System.out.println("i=" + i);//output=2

The new version does not assign the result of i++ to i, so the increment
side effect does not get overwritten by the value of i++.

I find this one easier to understand because eventually the new
bits do output. They don't get overwritten. In the original problem
there is overwriting going on that cause the 2 value to be lost
entirely. Is this due to the self-referencing aspect of the
original problem i=i++;?

It is not a self reference problem so much as an issue of multiple side
effects that act on the same data item. Generally, multiple side effects
in one statement make it harder to read and understand, and so should be
avoided. Code with multiple side effects on the same bits is a
particularly bad idea.

One last question: Where is that temp copy of the bits visible? I
can't see it in a debugger, so maybe I'm not using it (Eclipse) to
great advantage. I see the original i bits on the stack and that's
about it. This should not involve heap storage, so that leaves me
wondering where/how I'd ever see that temp set of bits.

The JVM can do it any way it likes, as long as it gets the proper
results and side effects. It is not required to make a temporary
variable anywhere that would be visible, as long as it ensures the
following:

1. Side effects happen in the proper order. Specifically, all side
effects of evaluating the right hand side of an assignment must happen
before the assignment.

2. The value of i++ is the old value of i.

Patricia

 

[Mike Schilling]

It is not a self reference problem so much as an issue of multiple side
effects that act on the same data item. Generally, multiple side effects
in one statement make it harder to read and understand, and so should be
avoided. Code with multiple side effects on the same bits is a
particularly bad idea.

Thought expermients:

1. Can "multiple side effects on the same bits" be defined clearly and
intuitively?
2. If so, would it be feasible to make statements that contain them illegal?
E.g.

i = i++;

wiuld cause a compilation error.

3. If so, would this be an improvement?

 

[John W. Kennedy]

Thought expermients:

1. Can "multiple side effects on the same bits" be defined clearly and
intuitively?

Both at once? Probably not. Otherwise, yes.

(By the way, this is Java we're talking about, so "same variable" will
suffice.)

2. If so, would it be feasible to make statements that contain them illegal?
E.g.

i = i++;

wiuld cause a compilation error.

I suspect so.

3. If so, would this be an improvement?

Well, some people would scream "Hand-holding!" and run off to
comp.lang.ruby to complain about the newest way Sun is Suppressing their
Creativity. (Note: I like Ruby. I use it a lot. But not beyond the
limits of Exodus 20:4-7.)

 

[Patricia Shanahan]

Thought expermients:

1. Can "multiple side effects on the same bits" be defined clearly and
intuitively?
2. If so, would it be feasible to make statements that contain them illegal?
E.g.

i = i++;

wiuld cause a compilation error.

I'm afraid not feasible to do exactly in general.

class MyClass{
int n;
}

MyClass p,q;
....

p.n = q.n++;

The two side effects in this statement affect the same bits if, and only
if, p and q reference the same MyClass instance. Whether that ever
happens is not, in general, a computable function of the source code.

Of course, one might do the equivalent of definite assignment, a set of
computable rules that prohibit all the bad cases, as well as some
non-problems.

3. If so, would this be an improvement?

It's too late now, but I think Java might have been a better language if
assignment, += etc., ++ and -- had all been made statements, rather than
expressions. That is, they would ONLY have side effects, not values.

There would still be more indirect multiple side effects, but generally
they are used in more restrained ways.

Patricia

 

[Stefan Ram]

As it happens, I don't hire Java compiler writers.

»Compiler suite test writer« is quite a different job than
»compiler writer«.

I also deem the answer prefered by you (»I would *never* write
code like that«) somewhat inappropriate. It is as if I'd ask
a student:

»What might happen to a human when he is touching
hydrochloric acid?«

and the student would answer:

»I would never perform an action like that.«

 

[Alex Hunsley]

I'm confused by the output of the following code:

public class PP {
public static void main(String[] args) {
int i = 1;
i = i++;
System.out.println(i);
}
}

It outputs 1.

I understand the assignment operator happening before the ++, but I don't
understand why the ++ doesn't increment. I thought the statement should
basically expand to:

i = i;
i = i+1;

but the ++ gets lots somewhere...

Other have answered the exact why. But anyway, this is a great
illustration of why you should only ever use, IMO, the increment
decrement operators in the simplest way, i.e.:

i++;

or

i--;

Otherwise, confusion results, as you've discovered. And of course, you
may write "i += 1" or "i -= 1" rather than the above form.

Python is a example of a language where they ditched the
increment/decrement operators, and at no loss, only benefit!

lex

 

[Alex Hunsley]

I'm confused by the output of the following code:

public class PP {
public static void main(String[] args) {
int i = 1;
i = i++;
System.out.println(i);
}
}

It outputs 1.

I understand the assignment operator happening before the ++, but I don't
understand why the ++ doesn't increment. I thought the statement should
basically expand to:

i = i;
i = i+1;

but the ++ gets lots somewhere...

No, it gets expanded into:

t = i;
i = i + 1;
i = t;

Don' do dat!

Holy crap! I hope no one ever asks me to evaluate code like that on a job
interview. I would never write code like that, but I doubt if I'd squirt
that nuance from the top of my head.

It's actually quite easy to derivce the code that John posted, if you
remember the core rule about "evaluation": post-increment operators like
i++ affect the value of the variable you apply them to *after* the whole
"i++ " expression is evaluated (and when you write "x = [something]",
you are evaluating the "[something]").
Pre-increment operators like ++i affect the value of i *before* i is
evaluated in the "i++" expression.

lex

 

[Mike Schilling]

»Compiler suite test writer« is quite a different job than
»compiler writer«.

I hire even fewer of them.

 

[sandy]

All Group Friends

The Ans. of this coding always remain 1.
because statement i=i++;
in this statement i's value assign to i and after assignment it
increases the value of i.
So, i's value is eqaul to 1.


Sumit Tanwar

 

[Patricia Shanahan]

All Group Friends

The Ans. of this coding always remain 1.
because statement i=i++;
in this statement i's value assign to i and after assignment it
increases the value of i.
So, i's value is eqaul to 1.

I agree with the conclusion, but don't see how it follows from your
model. It does, of course, follow from the model used in the JLS, as
discussed in several messages in this thread.

"i's value assign to i" would make i equal to 1. "after assignment it
increases the value of i" would change i from 1 to 2.

Patricia

 

[John Ersatznom]

Well, some people would scream "Hand-holding!" and run off to
comp.lang.ruby to complain about the newest way Sun is Suppressing their
Creativity. (Note: I like Ruby. I use it a lot. But not beyond the
limits of Exodus 20:4-7.)

70% of the planet's population won't have a bible handy when they reach
that statement.

I know I don't.

Actually quote it or at least link to it please.

 

[John W. Kennedy]

70% of the planet's population won't have a bible handy when they reach
that statement.

I know I don't.

<URL:http://www.bible.com> (among many, many others)

Thou shalt not make unto thee any graven image, or any likeness of
any thing that is in heaven above, or that is in the earth beneath, or
that is in the water under the earth.

Thou shalt not bow down thyself to them, nor serve them: for I the
LORD thy God am a jealous God, visiting the iniquity of the fathers upon
the children unto the third and fourth generation of them that hate me;

And shewing mercy unto thousands of them that love me, and keep my
commandments.

Thou shalt not take the name of the LORD thy God in vain; for the
LORD will not hold him guiltless that taketh his name in vain.

....which is infinitely too verbose for my original rhetorical purpose.\

 

[John Ersatznom]

<URL:http://www.bible.com> (among many, many others)

Thou shalt not make unto thee any graven image, or any likeness of
any thing that is in heaven above, or that is in the earth beneath, or
that is in the water under the earth.

Thou shalt not bow down thyself to them, nor serve them: for I the
LORD thy God am a jealous God, visiting the iniquity of the fathers upon
the children unto the third and fourth generation of them that hate me;

And shewing mercy unto thousands of them that love me, and keep my
commandments.

Thou shalt not take the name of the LORD thy God in vain; for the
LORD will not hold him guiltless that taketh his name in vain.

...which is infinitely too verbose for my original rhetorical purpose.\

Thanks -- though the URL you provided does not link to that specific
passage, and one that did would have sufficed without being "too verbose"