0 
if (false == x) { ...}

相对于：

if (!x) { ... }

和

if (false == f1()) { ...}

相对于：

if (!f1()) { ... }

我认为 if(false == ... 版本更具可读性。您同意，还是您可以提出另一个技巧？它会一样快吗？谢谢。

这就是我不喜欢 !x 的原因：

if (25 == a->function1(12345, 6789) &&
    45 == b->function1(12345, 6789) &&
    !c->someOtherFunction(123)) { ... }

以下似乎更好：

if (25 == a->function1(12345, 6789) &&
    45 == b->function1(12345, 6789) &&
    false == c->someOtherFunction(123)) { ... }
4

6 回答 6

7

我个人认为这种形式if (!x) { ... }最易读，但现在它们都将产生相同的代码。

编辑：在您的示例中，我将执行以下操作：

if (  a->function1(12345, 6789) == 25 &&
      b->function1(12345, 6789) == 45 &&
    !(c->someOtherFunction(123))) { ... }

但这实际上只是个人喜好。做对你来说最易读的事情。这不会有任何区别。

于 2009-12-16T00:54:07.367 回答
7

I think the if(false == ... version is more readable. Do you agree, or have another trick you can propose?

You're doing it wrong.

false == x returns a bool, which obviously has to be compared to true!

if (true == (false == x)) { ...} would be better. But that again returns a bool, so just to be on the safe side, and make your code more readable, we'd better do this:

if (true == (true == (false == x))) { ...}. And so on. Once you start comparing booleans to booleans, where do you stop? The result will always be another boolean, and to be consistent, you have to compare that to a boolean.

Or you could learn to understand the language you're working in, and use if (!x) { ...}, which expresses exactly what you wanted.

Which do you really think is more readable?

  • if (false == x) { ...} translates to "If it is true that false is equal to x".
  • if (!x) { ...} translates to "if x is not true".

Can you honestly, seriously, really say that the first form is "more readable"? Would you ever say that in a sentence? "If it is true that false is equal to x"?

It is not more readable, it just shouts to any programmer reading your code that "I don't understand if statements or boolean values".

于 2009-12-16T01:16:59.653 回答
4

C++ reserves the following keywords on the left as alternatives to the operators on the right:

and  and_eq  bitand    &&  &=  &
or   or_eq   bitor     ||  |=  |
     xor_eq  xor           ^=  ^
not  not_eq  compl     !   !=  ~

If you're worried about the ! getting lost, not stands out more.

if (    a->function1(12345, 6789) == 25 and
        b->function1(12345, 6789) == 45 and
        not c->someOtherFunction(123)) {
    ...
}
于 2009-12-16T01:49:21.997 回答
3

A good compiler should generate the same code for both code blocks.

However, instead of worrying about false == f1() vs. !f1(), you should be way more worried about the short-circuit evaluation in this example:

if (25 == a->function1(12345, 6789) &&
    45 == b->function1(12345, 6789) &&
    !c->someOtherFunction(123)) { ... }

Certain compilers will generate code that will skip the execution of b->function1() and c->someOtherFunction(), if a->function1() call happens to evaluate to something different than 25 - the reason being, the compiler already knows the outcome of the whole if () statement at that point, so it can jump at the right place.

If your code depends on a state being modified by any of the skipped functions, you might get nasty surprises.

于 2009-12-16T01:09:53.033 回答
2

This is a case of premature optimization (When is optimisation premature?). But the compiler will generate the same code (MSVC 2008 Debug mode):

if (!bVal)
    bVal = true;

if (bVal == false)
    bVal = true;

//translates to

; 70   :         if (!bVal)

cmp BYTE PTR $T5793[ebp], 0
jne SHORT $LN9@wmain
push    OFFSET $LN10@wmain
call    __RTC_UninitUse
add esp, 4
$LN9@wmain:
movzx   eax, BYTE PTR _bVal$[ebp]
test    eax, eax
jne SHORT $LN2@wmain

; 71   :             bVal = true;

mov BYTE PTR $T5793[ebp], 1
mov BYTE PTR _bVal$[ebp], 1
$LN2@wmain:

; 72   :         
; 73   :         if (bVal == false)

cmp BYTE PTR $T5793[ebp], 0
jne SHORT $LN11@wmain
push    OFFSET $LN10@wmain
call    __RTC_UninitUse
add esp, 4
$LN11@wmain:
movzx   eax, BYTE PTR _bVal$[ebp]
test    eax, eax
jne SHORT $LN1@wmain

; 74   :             bVal = true;

mov BYTE PTR $T5793[ebp], 1
mov BYTE PTR _bVal$[ebp], 1
于 2009-12-16T01:11:54.997 回答
1

您是否已分析并发现评估条件是热点？如果没有，那么按照您的编码标准要求做任何事情。

Both should compile to the same code anyway. You can check by inspecting the assembly code generated by the compiler for both cases.

于 2009-12-16T00:57:01.560 回答