-3

cut to the chase, the answer is "s is 20, and t cannot be determined." I understand the part that s is 20, but why t cannot be determined? Please help me!

Eugene Pi
  • 45
  • 2
  • 5
  • 4
    Where did you find the answer you're giving? – Joachim Isaksson Feb 11 '13 at 06:57
  • 1
    `t` can be determined: http://ideone.com/6ja0Kv – Paul Bellora Feb 11 '13 at 06:57
  • 2
    Did you think to, oh I don't know, try it and see? "t cannot be determined" is ... nonsense. – Brian Roach Feb 11 '13 at 06:59
  • 1
    Code like this is never useful in real life... why are you interested? – Jon Skeet Feb 11 '13 at 07:00
  • I think by "can be determined", he does not mean that it'll run, but that it's the same in all runtimes and all compilers. – Joachim Isaksson Feb 11 '13 at 07:00
  • @JoachimIsaksson - Then he'd ... still be wrong. – Brian Roach Feb 11 '13 at 07:02
  • @BrianRoach I'm fairly sure you're quite right that it _is_ 100% determined behavior in Java (in C/C++ for example, it's explicitly undefined behavior), but I'd not bet my house on it without looking at the spec. – Joachim Isaksson Feb 11 '13 at 07:07
  • The Q is tagged Java. If it were tagged C (or anything else where that wasn't the case) then I wouldn't have posted that ;) – Brian Roach Feb 11 '13 at 07:08
  • @BrianRoach I can bet my house now too :) http://stackoverflow.com/a/4978933/477878 – Joachim Isaksson Feb 11 '13 at 07:13
  • @JoachimIsaksson - Heh, I was just digging through the JLS to find that so I could post a link to it. I should have figured it was already here somewhere. – Brian Roach Feb 11 '13 at 07:15
  • 2
    Voting to reopen: While the expression is ugly and shouldn't be used in real code, I think this question isn't "too localized" because the answer is that it's well defined in Java (unlike C or C++) and follows very simple, natural rules of expression evaluation that Java *requires* be used. How can that be "too localized" if its a set of rules that every Java program must follow? It's important for Java developers to understand this (especially those who come from the world of C). – Michael Burr Feb 11 '13 at 07:21
  • 1
    For the record I voted "not a real question" because it was just an ugly question. If it were written as something coherent I wouldn't have. That being said, I should have closed it as a dup: http://stackoverflow.com/questions/11629136/preincrement-postincrement-in-java (among others, I'm sure) – Brian Roach Feb 11 '13 at 07:27
  • the answer is from myprogramminglab.com / our class in college use resources from that site. im not interested in code like that, either because it's very confusing. but i should submit my homework and that's one my homework problems :( – Eugene Pi Feb 11 '13 at 15:21
  • thank you for all of you! s is 20, and t is 40, I understand! i think the answer in that site was wrong – Eugene Pi Feb 11 '13 at 15:26

2 Answers2

2
int s = 20; 
int t = s++ + --s;

Working: increment(post increment) s to 21 (current value 20) + decrement(pre decrement) s to 20 (current value 20).

So, t=20+20;
And s =20;

After taking into account precedence and parentheses, Java guarantees that expressions will be evaluated left to right. For example, to evaluate eat() + drink() - beMerry(), Java will first evaluate eat(), then drink(), then perform the addition, then evaluate beMerry(), and finally perform the subtraction. eat() is evaluated before drink(), because eat() is to the left of drink(), and expressions are evaluated left to right. This guarantee is important because the invocations of eat() and drink() may have side effects that would differ if they were invoked in the opposite order.

Achintya Jha
  • 12,735
  • 2
  • 27
  • 39
0

Read this:

Since the increment/decrement operator modifies its operand, use of such an operand more than once within the same expression can produce undefined results. For example, in expressions such as x − ++x, it is not clear in what sequence the subtraction and increment operators should be performed. Situations like this are made even worse when optimizations are applied by the compiler, which could result in the order of execution of the operations to be different than what the programmer intended.

Now, you're answer should be pretty clear. It sounds to me like the value of t may vary by compiler/optimizations.

Here is some more info: http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Sequence-Points-Constrain-Expressions

Matt Wolfe
  • 8,924
  • 8
  • 60
  • 77