macOS Any thoughts on the comma operator (C/C++/Obj-C?)

gnasher729 said:

Very, very rare. This would be an example:

Code:

while (tmp = x*x + y*y, tmp > 10 && tmp < 20) { ... }

instead of

Code:

for (;;) {
    tmp = x*x + y*y; 
    if (tmp <= 10 || tmp >= 20) break;
    ...
}

Click to expand...

I used to write loops like the former, or try to. Then I spent way too much time trying to figure them out weeks later, or trying to debug them at the time. Now I only do it like the latter (though I usually put the break on its own indented line).


My thoughts regarding the comma operator:
1. It can make it difficult to set a breakpoint at a statement, if the statement is a bunch of comma-separated expressions. Better to make each one a separate statement.

2. There were times when an aggressive optimizer wouldn't rearrange the parts of a comma'ed statement, but it would rearrange statements with semicolons. I don't know how true that is any more, since optimizers are a lot better these days. Still, it wouldn't surprise me if commas aren't entirely interchangeable with semicolons when it comes to code rearrangement.

3. If you want to add something between the comma'ed expressions, it gets ugly very quickly. Even when the expressions may seem to be inseparable in the design, things can evolve and change over time.

4. One place where I still use commas is in the initializer (1st) or the iterator (3rd) clauses of a for loop, e.g.:
The fact that a continue in a for loop will go to the iterator part means that if there's more than one iterative calculation, you can guarantee that both are always done. However, there are also times when you DON'T want both things done, and for that I'd probably write it as a for (; so every conditional pathway was easy to follow.


EDIT

lee1210 said:

As for the difference between ; and , is that ; ends a statement and , joins statements and evaluates to the right operand.

Code:

x = haveFun(), eatPie(), takeNap();

Will result in x being set to the result of takeNap().

Click to expand...

I think the underlined part is incorrect. Assignment binds tighter than comma, so the assignment is done first, then eatPie() is called, then takeNap(). Effectively:

If this precedence weren't so, then this expression wouldn't work:
Since functions that return values can have the value ignored with little or no compiler complaint, the fact that takeNap() returns a value that's ignored would not cause the compiler to warn about it. Unexpected results ensue.

I don't have the time right now to write up a test case, but doing so would prove enlightening on several levels. One level is the fundamental operation of comma: its precedence, associativity, debuggability, etc. Another level is the potential confusion or errors when using it, even for skilled programmers with years of experience. I include myself in that bunch of confused error-makers, because I could be wrong. It's exactly the kind of thing I'd only trust after writing test code for, and frankly, if I have to write a test to figure out how it works, is it really worth using in real-world code? I could name all my variables as nothing but different numbers of _'s, too, but why would I do that except to sow confusion?