Would VS2008 c++ compiler optimize the following if statement?

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

as opposed to:

if (!x) { ... }

and

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

as opposed to:

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

I think the if(false == ... version is more readable. Do you agree, or have another trick you can propose? Will it be just as fast? Thanks.

This is why I do not like !x:

if (25 == a->function1(12345, 6789) &&
    45 == b->function1(12345, 6789) &&
    !c->someOtherFuncti开发者_Go百科on(123)) { ... }

The following seems better:

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

I personally find the form if (!x) { ... } most readable, but nowadays they're all going to result in the same code.

EDIT: In your example, I'd do the following:

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

But it's really just a personal preference thing. Do what's most readable to you. It's not going to make any difference.

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".

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)) {
    ...
}

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.

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

Have you profiled and found evaluating the condition to be a hot spot? If not, then do whatever your coding standard requires.

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