Take the 2-minute tour ×

So my friend gave me some source code to start out with so I could review and understand it and I have a question about it, but since he's not online I thought I would try here, mainly I don't quite understand this line.

num += i;

Essentially, this is the same as

num = num + i 


If you need more details please tell me! I look forward to hearing your replies soon.

share|improve this question

4 Answers 4

up vote 11 down vote accepted

From ISO C++03 (Section 5.17/7)

The behavior of an expression of the form E1 op= E2 is equivalent to E1 = E1 op E2 except that E1 is evaluated only once.

share|improve this answer
This is the best answer but hardest for me to understand, it took a second to understand what you meant by op but I got it. –  Samuraisoulification Sep 25 '10 at 7:05
The "evaluated only once" can make a significantdifference, for instance, if E1 is an indexed array position, where the index is not a constant. Example: arr[random()]=arr[random()]+1; vs. arr[random()]+=1; –  Lars D Sep 25 '10 at 7:19
nice find i did not know theres even an ISO for this. Thanks! –  nathan_hc Sep 25 '10 at 9:23
@Lars D: Assuming random() returns a [pseudo]random number, the expression arr[random()] = arr[random()] + 1 may modify different arr elements, which I think is not the intention. The concept of "Common Subexpression Eliminator" may be relevant: en.wikipedia.org/wiki/Common_subexpression_elimination –  Arun Sep 25 '10 at 22:49

Essentially yes, but it is more efficient. For basic types, like integers, using num += i increments the value of num directly, whereas num = num + i creates a temporary of the value of num, increments it, and then assigns it back to num.

share|improve this answer
It will make absolutely no difference with any modern compiler. –  Marcelo Cantos Sep 25 '10 at 6:51
Alright, thanks for the extra info, I'm really new to programming, I"m just going it with google, and some sites, and advice. So any info like that is nice to know. Now I know what it does, the difference, and that it doesn't matter nowadays. Thanks guys. –  Samuraisoulification Sep 25 '10 at 6:54
Yeah, any modern compiler should recognize them to be the same. The GCC compiler can do some amazing things when it comes to optimization. –  Kenny Cason Sep 25 '10 at 6:55

Yes. It is exactly the same (assuming you are talking about the built-in +=). In fact, this is how += is defined in the language specification.

Doesn't your favorite C++ book cover this topic?

share|improve this answer
Ah it says the same thing, I guess I skimmed the page too fast and missed it. :P Thanks man! –  Samuraisoulification Sep 25 '10 at 6:47
It is most certainly not the same thing, especially if num is not a primitive type. Classes can overload operator+ and operator+= to perform completely different operations (which is ill-advised, but quite legal). –  Marcelo Cantos Sep 25 '10 at 6:53
@Marcelo Cantos: That's why I added the "assuming you are talking about the built-in +=" bit. The term "built-in operator" in C++ terminology specifically refers to non-overloaded operator. For the built-in operator, once again, it is the same thing for the original examples. –  AndreyT Sep 25 '10 at 6:59

What will really happen there, as posted before, depends on the language. If one assumes C++, and that num is an integer, then as others have posted and as you have

num += i;

is equivalent to

num = num + i;

But it is really up to the class to determine that behavior in c++ / c#. You will essentially call the "+=" operator on the num object for the i object type. This should, in a good design, be the same as first performing the "+" operator, and then performing the = operator in the manner above. But it doesn't have to be:

 class foo
     bool operator += (int i) {return false;}

 foo num;
 int i;

 bool result = num += i;

In that example, num will be unchanged, and result will be false.

share|improve this answer
And it is really ill-advised to ever change the signature / meaning of an operator when overloading it, unless you are creating a DSEL of course. –  Matthieu M. Sep 25 '10 at 10:40
@Matthieu M - no doubt on that. I hope it didn't come across like I was saying that was in any way what should ever happen. If a class ever uses += to not be a combination of the + and = operators, the author has some 'splainin' ta do. –  PatrickV Sep 25 '10 at 19:52

Your Answer


