Tell me more ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 927 down vote favorite
183

Until today I thought that for example:

i += j;

is just a shortcut for:

i = i + j;

But what if we try this:

int i = 5;
long j = 8;

Then i = i + j; will not compile but i += j; will compile fine.

Does it mean that in fact i += j; is a shortcut for something like this i = (type of i) (i + j)?

I've tried googling for it but couldn't find anything relevant.

share|improve this question
184  
In my two years of lurking in StackOverflow, that was the nicest question so far. Congratulations, sir, you won my award. – baba Jan 3 '12 at 10:12
15  
The sad part is this question was asked within the last couple of weeks, but I can't find it here, or on Google. – Dave Newton Jan 3 '12 at 10:19
6  
(Not the one I'm looking for, but here's one.) stackoverflow.com/questions/608721/… – Dave Newton Jan 3 '12 at 10:28
3  
@Dave stackoverflow.com/questions/8137732/… – jontro Jan 3 '12 at 13:41
16  
For one thing, it is not a duplicate, they are exact opposites actually. For another, even if it was duplicate, given the trouble even an experienced user had finding it a new user certainly deserves to be congratulated. – Miserable Variable Jan 4 '12 at 1:32
show 7 more comments

8 Answers

up vote 644 down vote accepted

As always with these questions, the JLS holds the answer. In this case §15.26.2 Compound Assignment Operators. An extract:

A compound assignment expression of the form E1 op= E2 is equivalent to E1 = (T)((E1) op (E2)), where T is the type of E1, except that E1 is evaluated only once.

An example cited from §15.26.2

[...] the following code is correct:

short x = 3;
x += 4.6;

and results in x having the value 7 because it is equivalent to:

short x = 3;
x = (short)(x + 4.6);

In other words, your assumption is correct.

share|improve this answer
So i+=j compiles as I checked myself, but it would result in loss of precision right? If that's the case, why doesn't it allow it to happen in i=i+j also? Why bug us there? – ronnieaka Sep 22 '12 at 6:07
4  
@ronnieaka: I'm guessing that the language designers felt that in one case (i += j), it is safer to assume that the loss of precision is desired as opposed to the other case (i = i + j) – Lukas Eder Sep 22 '12 at 8:31
No, its right there, infront of me! Sorry i didn't notice it earlier. As in your answer, E1 op= E2 is equivalent to E1 = (T)((E1) op (E2)), so that's kind of like implicit down typecasting (down from long to int). Whereas in i = i+j, we have to do it explicitly, ie, provide the (T) part in E1 = ((E1) op (E2)) Isn't it? – ronnieaka Sep 22 '12 at 14:52
dku.rajkumar already had stated what i mean. should've looked down beyond your answer hehe – ronnieaka Sep 22 '12 at 14:55
up vote 18 down vote

you need to cast from long to int explicitly in case of i = i + l then it will compile and give correct output. like 

i = i + (int)l;

or

i = (int)((long)i + l); // this is what happens in case of += , dont need (long) casting since upper casting is done implicitly.

but in case of += it just works fine because the operator implicitly does the type casting from type of right variable to type of left variable so need not cast explicitly.

share|improve this answer
3  
In this case, the "implicit cast" could be lossy. In reality, as @LukasEder states in his answer, the cast to int is performed after the +. The compiler would (should?) throw a warning if it really did cast the long to int. – Romain Jan 3 '12 at 10:17
up vote 52 down vote

Very good question. The Java Language specification confirms your suggestion.

For example, the following code is correct:

short x = 3;
x += 4.6;

and results in x having the value 7 because it is equivalent to:

short x = 3;
x = (short)(x + 4.6);
share|improve this answer
up vote 29 down vote

Yes,

basically when we are writing 

i+=l;

compiler is converting this to 

  i = (int)(i + l);

I just checked the .class file code.

really a good thing to know

share|improve this answer
up vote 135 down vote

A good example of this casting is using *= or /=

byte b = 10;
b *= 5.7;
System.out.println(b); // prints 57

or

byte b = 100;
b /= 2.5;
System.out.println(b); // prints 40

or

char ch = '0';
ch *= 1.1;
System.out.println(ch); // prints '4'

or

char ch = 'A';
ch *= 1.5;
System.out.println(ch); // prints 'a'
share|improve this answer
2  
Hmm, that's an even better example than the JLS one... – Lukas Eder Jan 3 '12 at 10:22
@LukasEder cheers. ;) – Peter Lawrey Jan 3 '12 at 10:23
Yeah, you should have the JLS guys take that example from you! :) ... ok, now you're going mad on those examples ;-) – Lukas Eder Jan 3 '12 at 10:26
2  
@LukasEder going mad, is a polite way of putting it. ;) – Peter Lawrey Jan 3 '12 at 10:38
22  
+1 for *= on a char. – fluffy Jan 3 '12 at 21:44
up vote 3 down vote

The problem here is of type casting.

When you add int and long,

  1. The int object is casted to long & both are added and you get long object.
  2. but long object cannot be implicitly casted to int. So, you have to that explicitly.

But += is coded in such a way that it does type casting. i=(int)(i+m)

share|improve this answer
up vote 10 down vote

Please refer below link http://www.janeg.ca/scjp/oper/assignment.html

There it is mentioned that "all operators of the form op = cast their result to the type of the left-operand".

share|improve this answer
up vote 0 down vote

In Java type conversions are performed automatically when the type of the expression on the right hand side of an assignment operation can be safely promoted to the type of the variable on the left hand side of the assignment. Thus we can safely assign: byte -> short -> int -> long -> float -> double.The same will not work the other way round. For example we cannot automatically convert a long to an int because the first requires more storage than the second and consequently information may be lost. To force such a conversion we must carry out an explicit conversion. Type - Conversion

share|improve this answer

protected by Gilbert Le Blanc Feb 27 at 9:08

This question is protected to prevent "thanks!", "me too!", or spam answers by new users. To answer it, you must have earned at least 10 reputation on this site.

Not the answer you're looking for? Browse other questions tagged or ask your own question.