Why are pre- and post- inc/decrement operators implemented separately?

Question

I am trying to find the rationale behind having the re- and post- versions of the increment and decrement operators overloadable separately.
In my mind, and in every implementation I have ever seen of these operators for any type of class, these are the same operator (=do the same thing) and just differ in when it is called.
It would seem much more logical to me that the designers of C++ would have had one ++ operator, and the compiler would call it as needed, either before or after reading the value (or, more likely, at the previous or next sequence point, which I think is equivalent)

So, the question is: Does anyone have an example of a case/class where these might not be implemented the same? Or does anyone know/guess the rationale behind this design choice?

---

For those that prefer to look at code than read text in a question, here is the summary:

For what type T (a user defined class representing anything you want) would it make sense for the following 2 lines to not have the same side effects:

T v;

v++;
++v;

---

EDIT
To quote @Simple's comment below, which I hope clarifys the question:

Why post-increment (overloading) is in the language if the compiler can just do a copy itself and do the pre-increment

---

EDIT 2
Since the question is apparently unclear to many, here is another explanation:

Consider the following two lines:

b = a++;
b = ++a;

If it was one operator (for the sake of argument, I will call the operator +a+), the first line would be translated by the compiler into

b = a;
+a+;

and the second into

+a+;
b = a;

Answer 1

Pre increment increments the variable before the rest of the statement so for example

x = 2;
y = ++x;

y == 3;
x == 3;

Whereas post increment does the increment after the rest of the statement,

x = 2;
y = x++;

y == 2;
x == 3;

Pre increment is slightly faster so it should be preferred. Something to note is that when both operators are used in one statement the behaviour is undefined, so something like

x = 5;
x = x++ + ++x;

will give different results in different languages.

Answer 2

How would you implement a generic version of post-increment ?

I guess: T operator++(int) { T tmp(*this); ++*this; return tmp; }

What if my type is non-copiable, or expensive to copy ?

Well, I'd would prefer:

Proxy operator++(int) { return Proxy(++*this, 1); }

And then have things like:

bool operator==(Proxy const& left, T const& right) {
    return left.value - 1 == right.value;
}

Why post-increment (overloading) is in the language if the compiler can just do a copy itself and do the pre-increment ?

Because your assumption that the compiler can do the copy is erroneous, and even when it holds might be too costly.

Answer 3

This distinction becomes important in iterators over complex types. The expression

*it++

gives me the object the iterator currently points to, and increments the iterator. If the data would normally not be kept in memory after the iterator advances, returning the previous object becomes difficult. There are two approaches to this:

1. keep a copy in the postincrement
2. advance after delay

The former method still has to return something that behaves like an iterator (at least with regard to operator* and operator->, but cannot be a pointer because it also has to keep ownership of the copy of the object, so a proxy is returned:

struct iterator {
    value_type value;

    struct proxy {
        value_type value;
        value_type &operator*() { return value; }
        value_type *operator->() { return &value; }
    };

    value_type &operator*() { return value; }
    value_type *operator->() { return &value; }
    iterator &operator++(); // actual increment code
    proxy operator++(int) { proxy ret = { value }; ++*this; return ret; }
};

If creating a copy is expensive as well and should be avoided, you can also delay the increment:

struct iterator {
    value_type value;
    bool needs_increment;

    value_type &operator*() { if(needs_increment) ++*this; return value; }
    value_type *operator->() { if(needs_increment) ++*this; return &value; }
    iterator &operator++(); // actual increment code, resets needs_increment
    value_type *operator++(int) { needs_increment = true; return &value; }
};

Answer 4

Because of the separate semantics of these operators for built-in types. The value of the expression differs between pre and post increment/decrement, even though both change the operand.

int a = 1;
(a++) == 1;
a = 1;
(++a) == 2;

Allowing to overload them separately permits creating similar semantics for the return value.

Answer 5

Look at the following example

int i = 5;
int x = i++;
cout << i << " " << x;

This will print

6 5

int i = 5;
int x = ++i;
cout << i << " " << x;

This will print

6 6

So what can we infer?
In post-fix, the value of i is assigned to x first and then i is incremented
In pre-fix, the value of i is incremented first and then assigned to x

Answer 6

I think that the problem is related to the order of evaluation of (sub)expressions and the time of applying of side effects. For example in C# the order of evaluation of (sub)expressions is deterministic and side effects are applied at once. For example consider the following C# code

int x = 0;
int y = x++ + ++x;

This code has defined behaviour in C#. So you can implement only one increment operator and the compiler will use it the appropriate way.

C++ has no such a possibility. The order of evaluation of (sub)expressions is unspecified and side effects are not applied at once.

Answer 7

Perhaps something in a threaded environment that implements lazily? For ++a you want it to block until it has updated a so you get the updated value back, but for a++ you just send the signal and get on with things.

Answer 8

They are two separate operators because they do two different (albeit related) things.

Pre-increment/decrement will increment/decrement the variable and return the new value.

int i = 0;
int j = ++i; // j is now 1

Post-increment/decrement will increment/decrement the variable and return the old value.

int i = 0;
int j = i++; // j is now 0

In general, the implementation of these operators looks like this (for some type T):

T& T::operator++() // prefix overload
{
    *this = *this + 1;
    return *this;
}

T T::operator++(int) // postfix overload
{
    T prev = *this;
    ++(*this); // call prefix overload
    return prev;
}

As you can see, the prefix overload does not need an extra copy of the type, while the postfix version does.

As the bulk of the comments center around the question of why this is the case:

The short answer is: Because the C standard says so (and C++ inherited it from C).

The longer answer is:

++a and a++ are simply shorthand notation for calling specific functions. ++a (for a given type T) maps to either T& T::operator++() or T& operator++(T&) and a++ maps to either T T::operator++(int) or T operator(T&, int). As with all operators, you (as the programmer) can define them to do anything you want with respect to your corresponding type (Note: it is generally considered bad practice to overload an operator to do something strange, but the standard does not stop you from doing so). In general, if you are defining a type (e.g. an iterator), you would make it match the behavior of a built in type (e.g. a pointer) by providing a similar interface (i.e. overloading the proper operators). However, you could decide that you want operator++() to perform the quadratic formula and operator++(int) to take a Fourier Transform. As they are 2 separate functions, that is allowed. If the compiler was allowed to infer operator++(int) based on the on premise that it would be defined in terms of operator++(), they would be tied together.

Operators in C++ are nothing more than shorthand notation for function calls. While it is common to implement several operators in terms of others, it is not required by the standard, and thus the compiler cannot make such an assumption. If it were required by the standard, then there would be a lot of assumed behavior to keep track of.

Additionally, the behavior of ++a and a++ is a carry-over from C. There is a lot of code that exists that utilizes the behavior of one or the other, and changing that in the C++ standard would break compatibility with C (unless you also made the change in the C standard). As there is a lot of existing code that utilizes the behavior of these operators, you would be potentially making a large breaking change.

While it is quite common to implement post-increment in terms of pre-increment, you really should think of these two functions as different functions (much the same way you think of operator== vs operator!=, operator<, operator>, etc. Just because something is common does not mean the standard will, or even should, make it a requirement.