Hacker News Reader

Comment by hoverbear | Hacker News Reader

We don't have `++` and `--` in Rust either, and I really don't mind. The amount of times I've went to do a `++` where a `+= 1` was clutter has been perhaps one or two times.

Then again, my most common use for `++` was `for (;;) {}` index, and we have better in these new languages like Rust and Swift.

There are millions of people in this world trying to learn to code and understand the layers upon layers of cruft and quirks we've added. I don't mind the `++` or `--` operators, but I certainly don't mind them being gone either. They add extra complexity to code which is already arguably too complex.

In any case, I favor understandability over guesswork, and `++` is another odd cornercase which you have to mentally `grep` over.

View on HN

Oh, I've just closed a Haskell window, saw the title and thought "how would I concatenate strings?", but I'm digressing...

But no, not only for for(;;). There's also the too common array traversal:

while(something) a[x] = b[x++];

And lots and lots of ugly but useful uses in pointer arithmetics where they make things clear. They have no place in any other language, but I'd really miss both operators in C.

> while(something) a[x] = b[x++];

Wait, isn't this an undefined behavior? Is the order of evaluations of `x` in the left side and `x++` in the right side defined? I'm always confused at things like this!

I dunno. I always thought the ++ operator was evaluated after the entire statement, and every compiler that I could get my hands on behaved that way.

But, well, the specs are another matter entirely.

Hah, just this sort of confusion is part of the proposal to drop ++ and -- from Swift.

x++ returns x and then increments it, so yes the spec agrees with your intuition here.

Whereas ++x increments x and then returns the incremented x.

That subtle difference between x++ and ++x has been the debugging nightmare of many a C developer over the years. It's also why there's a fun irony in the C++ name and why people say the actual successor to C will be ++C.

What?

I was talking about my statement at the upper comment. I used x++ there, not ++x. The doubt is about the value of the other x.

The difference you talk is about the main behavior of the operators. You won't find any description of them that does not state it.

Well, I made the wrong assumption in what was being asked then, I guess. I would presume the "left to right" rule is more generally assumed knowledge in C/C++ than postfix/prefix distinction of ++/-- which are pretty much the only unary operators with such a distinction in the language, whereas "left to right" is a rather underlying general rule and one in which you generally assume people are familiar with.

My apologies for answering the wrong question, but yes in that case the standard is also mostly clear that you can assume that things are evaluated from left to right in C/C++ and thus the first x in the line should be evaluated prior to the x++ later in the line...

Just to update, yes, it's undefined behavior.

Every compiler seems to act the same way today, but some specs oriented optimizer might play havoc with that line.

Reply on news.ycombinator.com