Why does the C++ standard not deprecate the increment/decrement operators? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

I think the following code is evil, but it can be compiled without any warning.

int f(int n)
{
    return n + 1;
}

int n = 0;
n = f(n++) + f(++n);

I just wonder why the Holy Standard doesn't deprecate such operators?

I guess there might be two reasons:

One might be for backward compatibility;

Another might be for that under some cases these operators are very useful.

If the latter is true, could you give me some examples? Thanks.

Answer 1

It's more than evil, it's Undefined Behaviour™. Which is why all sane people ban such uses.

Backwards compatibility is surely half the problem- increment and decrement are used everywhere. They're also useful for iterators and stuff.

The bottom line is, C++ has never, ever stopped you from shooting yourself in the foot. This is just one example. C++ does not ban things that can be good just because they can be bad. Not abusing them is your problem.

Answer 2

To remove these ++ and -- operators from C and/or C++ would certainly break A LOT of code - in fact I suspect, if you remove those two operators, just about every single existing source file will stop compiling.

They are very useful when used correctly - as long as you don't use it on both sides of the same variable, you'll be fine.

This code won't compile, but adding parenthesis to make it (++n)++ does compile correctly - but g++ gives a warning "operation on ‘n’ may be undefined".

And if we remove the ++ and -- operator, how do you expect to write a common for-lopp:

for(int i = 0; i < 100; i++)

like this:

for(int i = 0; i < 100; i = i + 1)

or

for(int i = 0; i < 100; i += 1)

Banning everything that can be misused in C and C++ would pretty much reduce the language to nothing - and certainly either make the language completely useless or at least prevent a lot of valid uses. It'd be like banning knifes, because people CAN use them (and indeed have used them) for bad things. But if you want to cut bread, meat or vegetables, they do make darn handy tools for that purpose.

Answer 3

I just wonder why the Holy Standard doesn't deprecate such operators?

Because this is perfectly valid code, but it invokes unspecified behavior, since the order of evaluation of operands in a C expression isn't specified. The only problem in the code was created by the programmer, who has written code that relies on unspecified behavior. It is not the C standard's task to educate programmers about the language.

(This is not undefined behavior. See C11 6.5.2.2. There is a sequence point between the evaluations of the function designator and actual arguments in a function call and the actual call. Had it not been for the sequence point after each function parameter evaluation, it would have been undefined behavior, because you can't modify the same variable twice in an operation without a sequence point in between.)

One might be for backward compatibility;

No. C has always had unspecified order of evaluation of operands. This code works the same from pre-standard K&R code all the way to C11.

Another might be for that under some cases these operators are very useful.

No, the code you posted is not useful in any kind of scenario. It is obfuscated and can be written in better ways to achieve the very same functionality and identical machine code, in a safer, more readable way. For example:

n++;
n = f(n) + f(n);
n++;