Hacker News Reader

Comment by jagged-chisel | Hacker News Reader

    else *rwr-- = x;

No. Make that obvious and the PR can pass. Argue, and you're off the project.

View on HN

*foo++ (and --) is an extremely common C idiom. I'd argue it's clearer than the separated version.

As I experienced while trying to write out an AST for this pattern, the operator precedence makes it harder to read. I would at least prefer that it's written as *(foo++).

There are some badly chosen operator priorities in the C programming language that can make expressions without parentheses harder to read (e.g. for the bitwise operators), but the fact that postfix operators are executed before prefix operators is a very simple rule that is hard to forget, so for me adding such superfluous parentheses makes the expression harder to read, not easier to read.

To me, the parentheses make it significantly easier to read. They make it clear which operator directly acts on the variable, and create a mental meta-object to which the next operator acts.

I accept that if you're extremely used to writing this style of C code, it might be something that you're used to, and understand implicitly. As a C++ engineer that infrequently comes across this precise pattern, having the precedence made explicit makes it much easier to understand.

    else{
        *rwr--=x;
    }

Fine. I'll use inline asm then.

I sometimes wonder whether that's a better idea for these micro-optimizations, rather than looking at the assembly code and trying to coax the compiler into generating what you want.

That said, I'm not keen on "argue and you're off the project" work environment.

That would unironically be easier to understand than doing *rwr-- = x.

Reply on news.ycombinator.com