3 ms·

else *rwr-- = x; No. Make that obvious and the PR can pass. Argue, and you're off the project.

• xyzsparetimexyz 3mo ago
  Fine. I'll use inline asm then.
  • CodeMage 3mo ago
    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.
  • bigstrat2003 3mo ago
    That would unironically be easier to understand than doing *rwr-- = x.
• wiml 3mo ago
  *foo++ (and --) is an extremely common C idiom. I'd argue it's clearer than the separated version.
  • 14113 3mo ago
    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++).
    • adrian_b 3mo ago
      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.
      • 14113 3mo ago
        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.
• tom_ 3mo ago
  else{ *rwr--=x; }