There are two typical use cases for `++` and they should be considered separatly.

Firstly there is simply the `i++`, which is redundant with `i+=1`, but it's also very easy to understand syntactic sugar. Keep it or leave it, no big deal.

Then there is the more advanced and very subtle use of the return value:

  int i = 3;
  while (i--) {
      printf("%d, ", i);    // What does this print?
  }

This one is very controvertial. On one side, it simplifies and shortens code by a lot, but it also makes the code say too much at the same time. Can you tell by glance what this code would do? Personally, I prefer longer code and more expressive code, but I can also cut corners with the short version from time to time, when quickly testing something out.

EDIT: Fixed code formatting

I figured it would print 2, 1, 0, and was right, yay for me I guess. However my confidence was low.

I agree that you can write confusing code with ++, but that doesn't mean it should be banned! (Like they did with Swift). The ++ operators still are very useful. Also there are arguments that they're more correct than +=1 operations. I see ++ as meaning, "go to the next thing."

For example, the following operation sort of doesn't make sense:

  char c = f();
   c += 1;

Why are we adding an integer to a char? If you really wanted to be type safe, it should be

  c += '\001';

So you're adding a char to a char.

Same goes with pointers. They're memory addresses... but what happens of you add 1 to a memory address? Should you get the address plus one, or should you step over to the next object?

The issue I have with it is not evident in your code but add another printf after the while and it becomes slightly more problematic:

  int i = 3;
  while (i--) {
      printf("%d, ", i);    // What does this print?
  }
  printf("%d, ", i);

Nitpick: i += 1 is equivalent to ++i, not i++. i += 1 returns a value, too.

    2, 1, 0

Your code is just syntax sugar for assembler code. If you think in assembler instructions, you will have no problem with it.

Nope!

    2, 1, 0, %

where % is... I'm not sure what. What is that exactly?

It's probably your shell.

If you're using zsh:

> When a partial line is preserved, by default you will see an inverse+bold character at the end of the partial line: a ‘%’ for a normal user or a ‘#’ for root. If set, the shell parameter PROMPT_EOL_MARK can be used to customize how the end of partial lines are shown.

See http://zsh.sourceforge.net/Doc/Release/Options.html#Promptin...

I got `2, 1, 0,`

I read the instruction as: "Set i to 3. Subtract 1 then print until false."

    i = 3
    3 - 1 = 2, print
    2 - 1 = 1, print
    1 - 1 = 0, print
    0 = false, stop

I see a lot of people complain about using `--` like that but I fail to see what is unintuitive about it if you actually read the code and see what i is initialized as. =\

Ugh, never mind. I was misinterpreting that the shell was saying. See? Told you I'm dumb.

I'm glad it's the first time I see that code, instead of a usual for loop.

It doesn't compile in C++. Conditions have to be booleans. i-- is an integer :D

In C, 'true' is defined as anything else than '0', there is no proper boolean types, i-- is an integer which is perfectly okay for conditions, the condition is equivalent "while (i != 0)".

There might be some variations, errors and warnings depending on the compilers, the strictness level and the revision of the language chosen.

This is completely false, it compiles in C++ fine. Are you thinking of Java?

Well, it shouldn't. It's possible that you have to give a flag to the compiler to error on that kind of implicit casting. It should at least give a warning for sure.

I am definitely talking about C++

Compiles fine with -Wall -Werror. No warnings.

    int x = 1;
    bool y = x;

    # cl.exe /W3 main.c

This code gives a warning on VS2012. But it doesn't give one when the cast is in a loop condition. That is weird.

http://stackoverflow.com/a/31552168/5994461

This stackoverflow message talks about the specs for C11, and the first comment adds information on the C++03 spec. It seems that implicit cast from integer to boolean is allowed... under all circumstances... depending on what specification the compiler is following :D

For future references, I'll just summarize this as "C and C++ are minefields". We'll just add that to the list of WTF behaviors.

By the way, if you think that "C has had bool for 19 years" [the C99 spec specifically]. You clearly didn't work in C for long enough with a large variety of tools. The world is bigger than just GCC.

> But it doesn't give one when the cast is in a loop condition. That is weird.

I believe that the justification for that is that you'll often want to do e.g.

    while (node) {
      node.val += 3;
      node = node->next;
    }

Implicit conversion of a type into a bool is pretty useful here, or for e.g.

    while (std::cin >> x >> y) { ... }

I imagine the warning is following the rules for explicit constructors/operators in C++: an if condition is considered an "explicit" call to an `operator bool`. http://en.cppreference.com/w/cpp/language/explicit

The problem with ++ is not understanding what it does. It's remembering exactly how to use it appropriately in the given context, and never making a mistake. And, the affect is multiplied by C's semantics, specifically, given that off-by-one pointer shenanigans can lead to Very Bad Things. So, tricky to use thing that blows up big when it does blow up.

To make an analogy, I can perfectly understand null and what it does. My objection to null as a language feature is not based on not understanding it and what it does.

Have you heard of students learning to program in school? Seriously!

That's what Scratch is for!

Scratch++