Using bitwise operators for Booleans in C++

Question

Is there any reason not to use the bitwise operators &, |, and ^ for "bool" values in C++?

I sometimes run into situations where I want exactly one of two conditions to be true (XOR), so I just throw the ^ operator into a conditional expression. I also sometimes want all parts of a condition to be evaluated whether the result is true or not (rather than short-circuiting), so I use & and |. I also need to accumulate Boolean values sometimes, and &= and |= can be quite useful.

I've gotten a few raised eyebrows when doing this, but the code is still meaningful and cleaner than it would be otherwise. Is there any reason NOT to use these for bools? Are there any modern compilers that give bad results for this?

Answer 1

|| and && are boolean operators and the built-in ones are guaranteed to return either true or false. Nothing else.

|, & and ^ are bitwise operators. When the domain of numbers you operate on is just 1 and 0, then they are exactly the same, but in cases where your booleans are not strictly 1 and 0 – as is the case with the C language – you may end up with some behavior you didn't want. For instance:

BOOL two = 2;
BOOL one = 1;
BOOL and = two & one;   //and = 0
BOOL cand = two && one; //cand = 1

In C++, however, the bool type is guaranteed to be only either a true or a false (which convert implicitly to respectively 1 and 0), so it's less of a worry from this stance, but the fact that people aren't used to seeing such things in code makes a good argument for not doing it. Just say b = b && x and be done with it.

Answer 2

I think

a != b

is what you want

Answer 3

Disadvantages of the bitlevel operators.

You ask:

“Is there any reason not to use the bitwise operators &, |, and ^ for "bool" values in C++? ”

Yes, the logical operators, that is the built-in high level boolean operators !, && and ||, offer the following advantages:

• Guaranteed conversion of arguments to bool, i.e. to 0 and 1 ordinal value.

• Guaranteed short circuit evaluation where expression evaluation stops as soon as the final result is known.
  This can be interpreted as a tree-value logic, with True, False and Indeterminate.

• Readable textual equivalents not, and and or, even if I don't use them myself.
  As reader Antimony notes in a comment also the bitlevel operators have alternative tokens, namely bitand, bitor, xor and compl, but in my opinion these are less readable than and, or and not.

Simply put, each such advantage of the high level operators is a disadvantage of the bitlevel operators.

In particular, since the bitwise operators lack argument conversion to 0/1 you get e.g. 1 & 2 → 0, while 1 && 2 → true. Also ^, bitwise exclusive or, can misbehave in this way. Regarded as boolean values 1 and 2 are the same, namely true, but regarded as bitpatterns they're different.

---

How to express logical either/or in C++.

You then provide a bit of background for the question,

“I sometimes run into situations where I want exactly one of two conditions to be true (XOR), so I just throw the ^ operator into a conditional expression.”

Well, the bitwise operators have higher precedence than the logical operators. This means in particular that in a mixed expression such as

a && b ^ c

you get the perhaps unexpected result a && (b ^ c).

Instead write just

(a && b) != c

expressing more concisely what you mean.

For the multiple argument either/or there is no C++ operator that does the job. For example, if you write a ^ b ^ c than that is not an expression that says “either a, b or c is true“. Instead it says, “An odd number of a, b and c are true“, which might be 1 of them or all 3…

To express the general either/or when a, b and c are of type bool, just write

(a + b + c) == 1

or, with non-bool arguments, convert them to bool:

(!!a + !!b + !!c) == 1

---

Using &= to accumulate boolean results.

You further elaborate,

“I also need to accumulate Boolean values sometimes, and &= and |=? can be quite useful.”

Well, this corresponds to checking whether respectively all or any condition is satisfied, and de Morgan’s law tells you how to go from one to the other. I.e. you only need one of them. You could in principle use *= as a &&=-operator (for as good old George Boole discovered, logical AND can very easily be expressed as multiplication), but I think that that would perplex and perhaps mislead maintainers of the code.

Consider also:

struct Bool
{
    bool    value;

    void operator&=( bool const v ) { value = value && v; }
    operator bool() const { return value; }
};

#include <iostream>

int main()
{
    using namespace std;

    Bool a  = {true};
    a &= true || false;
    a &= 1234;
    cout << boolalpha << a << endl;

    bool b = {true};
    b &= true || false;
    b &= 1234;
    cout << boolalpha << b << endl;
}

Output with Visual C++ 11.0 and g++ 4.7.1:

true
false

The reason for the difference in results is that the bitlevel &= does not provide a conversion to bool of its right hand side argument.

So, which of these results do you desire for your use of &=?

If the former, true, then better define an operator (e.g. as above) or named function, or use an explicit conversion of the right hand side expression, or write the update in full.

Answer 4

Contrary to Patrick's answer, C++ has no ^^ operator for performing a short-circuiting exclusive or. If you think about it for a second, having a ^^ operator wouldn't make sense anyway: with exclusive or, the result always depends on both operands. However, Patrick's warning about non-bool "Boolean" types holds equally well when comparing 1 & 2 to 1 && 2. One classic example of this is the Windows GetMessage() function, which returns a tri-state BOOL: nonzero, 0, or -1.

Using & instead of && and | instead of || is not an uncommon typo, so if you are deliberately doing it, it deserves a comment saying why.

Answer 5

Using bitwise operations for bool helps save unnecessary branch prediction logic by the processor, resulting from a 'cmp' instruction brought in by logical operations.

Replacing the logical with bitwise operations (where all operands are bool) generates more efficient code offering the same result. The efficiency ideally should outweigh all the short-circuit benefits that can be leveraged in the ordering using logical operations.

This can make code a bit un-readable albeit the programmer should comment it with reasons why it was done so.

Answer 6

Patrick made good points, and I'm not going to repeat them. However might I suggest reducing 'if' statements to readable english wherever possible by using well-named boolean vars.For example, and this is using boolean operators but you could equally use bitwise and name the bools appropriately:

bool onlyAIsTrue = (a && !b); // you could use bitwise XOR here
bool onlyBIsTrue = (b && !a); // and not need this second line
if (onlyAIsTrue || onlyBIsTrue)
{
 .. stuff ..
}

You might think that using a boolean seems unnecessary, but it helps with two main things:

• Your code is easier to understand because the intermediate boolean for the 'if' condition makes the intention of the condition more explicit.
• If you are using non-standard or unexpected code, such as bitwise operators on boolean values, people can much more easily see why you've done this.

EDIT: You didnt explicitly say you wanted the conditionals for 'if' statements (although this seems most likely), that was my assumption. But my suggestion of an intermediate boolean value still stands.