whether a language needs preIncrement (++x) and postIncrement (x++)_问答_开发者

I have never seen the usecase for pre-increment and post-increment in actual code. The only place i see them most often are puzzles.

My opinion is, it introduces more confusion rather开发者_如何转开发 than being useful.

is there any real use case scenario for this
can't this can be done by using +=

y = x++

y = x
x += 1

It's just a shorter way of writing the same thing and it's only confusing to those who don't deeply understand C ^(a). The same argument could be made for replacing:

for (i = 0; i < 10; i++)
    printf ("%d\n", i);

with:

i = 0;
while (i < 10) {
    printf ("%d\n", i);
    i = i + 1;
}

since any for can also be done with while, or:

i = 0;
loop: if (i < 10) {
    printf ("%d\n", i);
    i = i + 1;
    goto loop;
}

since any loop construct can be built out of conditions and goto. But (I'm hoping) you wouldn't do that, would you?

^(a) I sometimes like to explain this to my students as simple statements and side effects, something that allows C code to be more succinct with usually no or minimal loss in readability.

For the statement:

y = x++;

the statement is assigning x to y with the side effect that x is incremented afterwards. ++x is the same, it's just that the side effect happens beforehand.

Similarly, the side effect of an assignment is that it evaluates as the value assigned, meaning you can do things like:

while ((c = getchar()) != -1) count++;

and which makes things like:

42;

perfectly valid, but useless, C statements.

The pre- and post-increment operators make much more sense if you consider them in the light of history and when they were conceived.

Back in the days when C was basically a high-level assembler for PDP-11 machines</flamebait>, and long before we had the nice optimizing compilers we have now, there were common idioms used that the post-increment operators were perfect for. Things like this:

char* strcpy(char* src, char* dest)
{
  /* highly simplified version and likely not compileable as-is */
  while (*dest++ = *src++);
  return dest;
}

The code in question generated PDP-11 (or other) machine language code that made heavy use of the underlying addressing modes (like relative direct and relative indirect) that incorporated exactly these kinds of pre- and post-increment and decrement operations.

So to answer your question: do languages "need" these nowadays? No, of course not. It's provable that you need very little in terms of instructions to compute things. The question is more interesting if you ask "are these features desirable?" To that I'd answer a qualified "yes".

Using your examples:

y = x;
x += 1;

vs.

y = x++;

I can see two advantages right off the top of my head.

The code is more succinct. Everything I need to know to understand what you're doing is in one place (as long as I know the language, naturally!) instead of spread out. "Spreading out" across two lines seems like a picky thing but if you're doing thousands of them it can make a big difference in the end.
It is far more likely that the code generated even by a crappy compiler will be atomic in the second case. In the first case it very likely will not be unless you have a nice compiler. (Not all platforms have good, strong optimizing compilers.)

Also, I find it very telling that you're talking about += when that itself is an "unneeded" way of saying x = x + 1;.... After all there is no use case scenario I can think of for += that couldn't be served fine by _ = _ + _ instead.

You're accidentally raising a much larger issue here, and it's one that will make itself more and more known to you as the years (decades) go by.

Languages often make the mistake of supplying "abilities" when they shouldn't. IMO, ++ should be a stand-alone statement only, and absolutely not an expression operator.

Try to keep the following close to heart: The goal is not to create code for the competent engineer to read. The goal is to create code for the competent engineer to read when he is exhausted at 3am and hopped up on caffeine.

If an engineer says to you "All code constructs can get you into trouble. You just have to know what you're doing.", then walk away laughing, because he's just exposed himself as part of the problem.

In other words, please don't ever code anything like this: