-2

I wonder what is better to compute in C language:

if (x==0) 
{
    // Some code ...
}

of

if (0==x) 
{
    // Some code ...
}

I know the last is better in case the programmer forgets the second "=" and write "0 = x" instead "0 == x" because the compiler will throw an error.

But my question is:

  1. From the processor's perspective, in compute time.
  2. In general (not just for AMD/Intel CPU, also for embedded components with different processors.

I think that related to "lvalue" and "rvalue", and I try to simulate in my PC, without significant insights.

Eviatar
  • 1
  • 2
    Build both, with optimizations enabled, and look at the generated assembly code. Is it the same or different? I'll bet it would be the same. Compilers are pretty smart, especially when it comes to [commutative](https://en.wikipedia.org/wiki/Commutative_property) operators like `==`. – Some programmer dude May 10 '23 at 06:03
  • Yes it both compiles to the same, see [this example](https://godbolt.org/z/En3ojj34j). The assembly lines 12 - 14 do the same comparison and calls as 16 - 18. – Joel May 10 '23 at 06:07
  • maybe for PC compiler, how about embedded components? some of them have much simplifier CPU (or even MPU) – Eviatar May 10 '23 at 06:16
  • 2
    Hard to imagine a compiler making worse code for one of these cases, since the meaning is identical. Even in a debug build (unoptimized), you'll probably get the same asm. Any compiler with optimization enabled should definitely make equally good asm, normally the same asm, for both ways. It's nothing to do with the complexity of the CPU / microcontroller, just about the compiler and the fact that comparing a value against zero is the same however you write it. CPUs run machine code, not C directly. – Peter Cordes May 10 '23 at 06:18
  • Let me instead ask you this: What would you expect to be faster, `a + b` or `b + a`? Comparison using `==` or `!=` are basically the same as `+` or `*`, and the order doesn't matter. That's what makes these operators *commutative*. – Some programmer dude May 10 '23 at 06:20
  • 3
    "I know the last is better in case the programmer forgets the second =" No! That argument is from the 1980s and comes with a strange 1980s obfuscation religion called "The Yoda conditions". The last argument for writing weird code like that died in 1989 when Turbo C started to warn about "possible assignment inside condition". Since then all good compilers have such a warning and the only reason for obfuscating code like in the 1980s are religious, not rational. – Lundin May 10 '23 at 08:04
  • @lundin yes, but who looks at warnings when there's thousands and thousands generated? (p.s. I personally don't put up with it, but I've worked too many places where warnings were completely tolerated. surprisingly they always had horrible QC and could never release on time and somehow couldn't figure out why) – Russ Schultz May 10 '23 at 13:44
  • 2
    @RussSchultz If you have thousands of warnings in your project, it is very likely broken beyond repair... Contrary to popular belief, a warning doesn't mean "here's a cosmetic little tiny issue that you are free to ignore" but rather "here is a serious bug which you need to fix". The only difference between warnings and errors are that errors tend to be restricted to the things that the C language makes mandatory to report: syntax and constraint violations. – Lundin May 10 '23 at 13:54

1 Answers1

5

There is no general answer. The actual computing time depends on the target system and the compiler and its optimization.

If you disable all optimization, you might observe different machine code generated, and that could possibly have different computing time.

However, modern compilers optimize your code in many ways. You can expect that both variants generate the same machine code.

To be sure about your system, compile both variants and look at the generated machine code. Serious compilers have options or tools to produce a listing.

Conclusion: If you do not experience performance problems, do not micro-optimize. Write the source in the best way to be safe against human errors, and to be the easiest to understand. (BTW, Yoda conditions tend to be understood harder.)

The terms "rvalue" is only used twice in the standard, one time in a note:

What is sometimes called "rvalue" is in this document described as the "value of an expression".

And the second time in the index, pointing to this note. Apparently it is not used any more.

The equality operator does not differentiate between its operands. Both are of the same kind.

the busybee
  • 10,755
  • 3
  • 13
  • 30