Why are multiple pre-increments allowed in C++ but not in C?

Question

Why is

int main()
{
    int i = 0;
    ++++i;
}

valid C++ but not valid C?

Answer 1

C and C++ say different things about the result of prefix ++. In C++:

[expr.pre.incr]

The operand of prefix ++ is modified by adding 1. The operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic type other than cv bool, or a pointer to a completely-defined object type. The result is the updated operand; it is an lvalue, and it is a bit-field if the operand is a bit-field. The expression ++x is equivalent to x+=1.

So ++ can be applied on the result again, because the result is basically just the object being incremented and is an lvalue. In C however:

6.5.3 Unary operators

The operand of the prefix increment or decrement operator shall have atomic, qualified, or unqualified real or pointer type, and shall be a modifiable lvalue.

The value of the operand of the prefix ++ operator is incremented. The result is the new value of the operand after incrementation.

The result is not an lvalue; it's just the pure value of the incrementation. So you can't apply any operator that requires an lvalue on it, including ++.

If you are ever told the C++ and C are superset or subset of each other, know that it is not the case. There are many differences that make that assertion false.

Answer 2

In C, it's always been that way. Possibly because pre-incremented ++ can be optimised to a single machine code instruction on many CPUs, including ones from the 1970s which was when the ++ concept developed.

In C++ though there's the symmetry with operator overloading to consider. To match C, the canonical pre-increment ++ would need to return const &, unless you had different behaviour for user-defined and built-in types (which would be a smell). Restricting the return to const & is a contrivance. So the return of ++ gets relaxed from the C rules, at the expense of increased compiler complexity in order to exploit any CPU optimisations for built-in types.

Answer 3

I assume you understand why it's fine in C++ so I'm not going to elaborate on that.

For whatever it's worth, here's my test result:

t.c:6:2: error: lvalue required as increment operand
  ++ ++c;
  ^

Regarding CppReference:

Non-lvalue object expressions

Colloquially known as rvalues, non-lvalue object expressions are the expressions of object types that do not designate objects, but rather values that have no object identity or storage location. The address of a non-lvalue object expression cannot be taken.

The following expressions are non-lvalue object expressions:

• all operators not specified to return lvalues, including

  • increment and decrement operators (note: pre- forms are lvalues in C++)

And Section 6.5.3.1 from n1570:

The value of the operand of the prefix ++ operator is incremented. The result is the new value of the operand after incrementation.

So in C, the result of prefix increment and prefix decrement operators are not required to be lvalue, thus not incrementable again. In fact, such word can be understood as "required to be rvalue".

Answer 4

The other answers explain the way that the standards diverge in what they require. This answer provides a motivating example in the area of difference.

In C++, you can have a function like int& foo(int&);, which has no analog in C. It is useful (and not onerous) for C++ to have the option of foo(foo(x));.

Imagine for a moment that operations on basic types were defined somewhere, e.g. int& operator++(int&);. ++++x itself is not a motivating example, but it fits the pattern of foo above.