Why post-increment needs to make a copy while pre-increment does not

Question

I know this issue has been discussed several times , but I could not find a post which explains why a copy needs to be made in case of a post-increment operation.

Quoting from a stackoverflow reply:

int j = i++; // j will contain i, i will be incremented.
int j = ++i; // i will be incremented, and j will contain i+1.

Which perfectly makes sense when the definition of post/pre increment is considered. Many times when comparing the performance of pre/post increment it is said that post increment needs to make a copy, increment it and return the copy while pre-increment just increases value and does not create a copy.

Although performance has been compared in tens of posts, I really could not find any explanation on why a copy has to be made in the case of post-increment. Why doesn't it return the old value and then increments the value of the variable by one(or however way operator is overloaded), rather than creating a new object and return that one.

Because post-increment must keep previous value in a temporary so to return it afterwards. — 101010, Jun 19 '15 at 15:33
`Why doesn't it return the old value and then increments the value of the variable by one` How do you increment the value if you already returned from the function? — AliciaBytes, Jun 19 '15 at 15:34
@RaphaelMiedl thanks raphael, that was exactly the point I was missing. I knew it was something very trivial :) — ralzaul, Jun 19 '15 at 15:37
possible duplicate of [Is there a performance difference between i++ and ++i in C++?](http://stackoverflow.com/questions/24901/is-there-a-performance-difference-between-i-and-i-in-c) — 101010, Jun 19 '15 at 15:37
The example is somewhat bad since the compiler can (and almost certainly will) trivially transform the first variant into `int j = i; ++i`, so there is really no temporary (still the compiler complies perfectly with the as-if rule). But there are cases when it's not that easy, especially on types with non-trivial constructors, or think of barriers/memory model which may disallow such a liberal instruction reordering. — Damon, Jun 19 '15 at 16:38

NathanOliver · Accepted Answer · 2016-11-24T14:41:52.210

12

The difference is someval++ returns what someval is before the increment and to do that you need remember what someval is with a copy. How else would you return the original value while updating it if the original value wasn't stored somewhere?

edited Nov 24 '16 at 14:41

answered Jun 19 '15 at 15:33

NathanOliver

171,901
28
288
402

score 10 · Answer 2 · answered Jun 19 '15 at 15:39

Consider pre-incrementation and post-incrementation operators as standard functions:

// ++i
int pre_increment(int &i) {
    i = i + 1;
    return i;
}

// i++
int post_increment(int &i) {
    int original_i = i;
    i = i + 1;
    return original_i;
}

This should help you to understand why in the second case (i++), you MUST perform a copy of the value before doing the incrementation.

R Sahu · Answer 3 · 2015-06-19T16:52:34.613

It's hard for me to say how compilers can optimize the pre-increment and post-increment operators so that a copy is not necessarily made on primitive types.

I can show how a copy needs to be made for user defined types for the post-increment operators.

Lets' take a simplistic look at std::vector::iterator.

Let's say the iterator stores an index, in addition to the other things.

struct iterator
{
   size_t index;

   iterator operator++(int )
   {
      iterator copy = *this;
      this->index++;
      return copy;
   }
 };

In such a case, it is not possible to return *this first and then increment the index. Creating a copy, incrementing the index of this, and then returning the copy allows us to preserve the semantics of that operation.

Why post-increment needs to make a copy while pre-increment does not

3 Answers3

Linked