Does "if ([bool] == true)" require one more step than "if ([bool])"?

Question

This is a purely pedantic question, to sate my own curiosity.

I tend to go with the latter option in the question (so: if (boolCheck) { ... }), while a coworker always writes the former (if (boolCheck == true) { ... }). I always kind of teased him about it, and he always explained it as an old habit from when he was first starting programming.

But it just occurred to me today that actually writing out the whole == true part may in fact require an additional step for processing, since any expression with a == operator gets evaluated to a Boolean value. Is this true?

In other words, as I understand it, the option without the == true line could be loosely described as follows:

1. Check X

While the option with the == true line would be more like:

1. Let Y be true if X is true, otherwise false
2. Check Y

Am I correct? Or perhaps any normal compiler/interpreter will do away with this difference? Or am I overlooking something, and there's really no difference at all?

Obviously, there will be no difference in terms of actual observed performance. Like I said, I'm just curious.

EDIT: Thanks to everyone who actually posted compiled results to illustrate whether the steps were different between the two approaches. (It seems, most of the time, they were, albeit only slightly.)

I just want to reiterate that I was not asking about what is the "right" approach. I understand that many people favor one over the other. I also understand that, logically, the two are identical. I was just curious if the actual operations being performed by the CPU are exactly the same for both methods; as it turns out, much of the time (obviously it depends on language, compiler, etc.), they are not.

Answer 1

I would expect the difference to be optimised away by any half-decent compiler.

(I just checked with C# and the compiled code is exactly the same for both syntaxes.)

Answer 2

It depends on the compiler. There might be optimizations for either case.

Answer 3

There is no logical difference, presuming there is no internal typecasting going on, e.g., testing fstream.

ifstream fin;
...
if( ! fin)
...

Answer 4

The compiler should generate the same code. However, comparing with true is arguably better because it is more explicit. Generally I don't do the explicit comparison, but you shouldn't make fun of him for doing it.

Edit: The easiest way to tell is to try. The MS compiler (cl.exe) generates the same number of steps in assembly:

int _tmain(int argc, _TCHAR* argv[])
{
    bool test_me = true;

    if (test_me) {
004113C2  movzx       eax,byte ptr [test_me] 
004113C6  test        eax,eax 
004113C8  je          wmain+41h (4113E1h) 
        printf("test_me was true!");
    }

    if (test_me == true) {
004113E1  movzx       eax,byte ptr [test_me] 
004113E5  cmp         eax,1 
004113E8  jne         wmain+61h (411401h) 
        printf("still true!");
    }
    return 0;
}

At this point the question is do test and cmp have the same cost? My guess is yes, though experts may be able to point out differences.

The practical upshot is you shouldn't worry about this. Chances are you have way bigger performance fish to fry.

Answer 5

I think the comparison with true shows a lack of understanding by your partner. Bools should be named things to avoid this (such as isAvaliable: if (isAvailable) {...}).

Answer 6

The MSVC++ 6.0 compiler generates slightly different code for the two forms:

4:        if ( ok ) {
00401033   mov         eax,dword ptr [ebp-8]
00401036   and         eax,0FFh
0040103B   test        eax,eax
0040103D   je          main+36h (00401046)
....
7:        if ( ok == true ) {
00401046   mov         ecx,dword ptr [ebp-8]
00401049   and         ecx,0FFh
0040104F   cmp         ecx,1
00401052   jne         main+4Bh (0040105b)

The former version should be very slightly faster, if I remember my 8086 timings correctly :-)

Answer 7

Here's the Python (2.6) disassembly:

>>> def check(x): return (bool(x) == True)

>>> import dis
>>> dis.dis(check)
  1           0 LOAD_GLOBAL              0 (bool)
              3 LOAD_FAST                0 (x)
              6 CALL_FUNCTION            1
              9 LOAD_GLOBAL              1 (True)
             12 COMPARE_OP               2 (==)
             15 RETURN_VALUE        
>>> def check2(x): return bool(x)

>>> dis.dis(check2)
  1           0 LOAD_GLOBAL              0 (bool)
              3 LOAD_FAST                0 (x)
              6 CALL_FUNCTION            1
              9 RETURN_VALUE

I suppose the reason check isn't optimized is due to Python being a dynamic language. This in itself doesn't mean Python uses a poor compiler, but it could stand to do a little type inference here. Maybe it makes a difference when a .pyd file is created?

Answer 8

This gets into specific languages and what they consider "truthy" values. Here's two common ones: JavaScript and PHP.

The triple equals operator in both these languages assures that you really are checking for a boolean type of truth. For example, in PHP checking for if ($value) can be different from if ($value==true) or if ($value===true):

$f = true;
$z = 1;
$n = null;
$a = array(1,2);

print ($f)        ?'true':'false'; // true
print ($f==true)  ?'true':'false'; // true
print ($f===true) ?'true':'false'; // true
print "\n";
print ($z)        ?'true':'false'; // true
print ($z==true)  ?'true':'false'; // true
print ($z===true) ?'true':'false'; // false
print "\n";
print ($n)        ?'true':'false'; // false
print ($n==true)  ?'true':'false'; // false
print ($n===true) ?'true':'false'; // false
print "\n";
print ($a)        ?'true':'false'; // true
print ($a==true)  ?'true':'false'; // true
print ($a===true) ?'true':'false'; // false
print "\n";
print "\n";

I expect that languages one speaks daily will inform how one views this question.

Answer 9

Testing for equality to true can lead to a bug, at least in C: in C, 'if' can be used on integer types (not just on boolean types), and accept any non-zero value; however the symbol 'TRUE' is one specific non-zero value (e.g. 1). This can become important with bit-flags:

if (flags & DCDBIT)
{
    //do something when the DCDBIT bit is set in the flags variable
}

So given a function like this ...

int isDcdSet()
{
    return (flags & DCDBIT);
}

... the expression "if (isDcdSet())" is not the same as "if (isDcdSet() == TRUE)".

Anyway; I'd think that an optimizing compiler should optimize away any difference (because there is no logical difference), assuming it's a language with a true boolean (not just integer) type.

Answer 10

It may not be the same if you are working with a nullable bool.

Example:

Bool? myBool = true

if(myBool)  // This will not compile

if(myBool == true)  //this will compile

Answer 11

Duplicate question (http://stackoverflow.com/questions/356217/should-i-use-isgood-or-isgood-false). Here's a pointer to my previous answer:

The technique of testing specifically against true or false is bad practice if the variable in question is really supposed to be used as a boolean value (even if its type is not boolean) - especially in C/C++. Testing against true can (and probably will) lead to subtle bugs.

See the following SO answer for details:

http://stackoverflow.com/questions/356217/should-i-use-isgood-or-isgood-false/356709#356709

Answer 12

There may be some justification in the "boolCheck == true" syntax dependning on the name of the variable you're testing.

For example, if the variable name was "state", then you can either have:

if (state) {
   ...
}

or you can have

if (state == true) {
   ...
}

In this case, I think the latter form is clearer and more obvious.

Another example would be a variable like "enabled", in which case the first form is clearer.

Now having a boolean variable called "state" is bad practice, but you may have no control over that, in which case the "== true" syntax may improve code readability.

Answer 13

In my experience if (flag==true) is bad practice.

The first argument is academic:

If you have a bool flag, it is either true or false.

Now, the expression

(flag==true)

again, is true or false - it is no more expressive, only redundant - flag can't get "more true" or "more false" than it already is. It would be "clearer" only reason only if it's not obvious flag is a boolean - but there's a standard way to fix that which works for all types: choose a better name.

Stretching this beyond reaso, the following would be "even better":

((flag==true)==true)

The second argument is pragmatic and platform-specific

C and early C++ implementations had no real "bool" type, so there are different conventions for flags, the most common being anything nonzero is true. It is not uncommon for API's to return an integer-based BOOL type, but not enforce the return value to be 0 or 1.

Some environments use the following definitions:

#define FALSE 0
#define TRUE (!FALSE)

good luck with if ((1==1) == TRUE)

Further, some platforms use different values - e.g. the VARIANT_BOOL for VB interop is a short, and VARIANT_TRUE is -1.

When mixing libraries using these definitions, an explicit comparison to true can easily be an error disguised as good intentions. So, don't. When mixing such code,

Answer 14

IMHO it's a bad idea to use the if (boolCheck == true) form, for a simple reason : if you accidentally type a single 'equals' sign instead of a double (i.e. if (boolCheck = true)), it will assign true to boolCheck and will always return true, which would obviously be a bug. Of course, most modern compilers will show a warning when they see that (at least the C# compiler does), but many developers just ignore warnings...

If you want to be explicit, you should prefer this form: if (true == boolCheck). This will avoid accidental assignation of the variable, and will cause a compile error if you forget an 'equals' sign.