Did you know that '&' can be a logical AND operator? [modified]

Rajasekharan Vengalil

I almost lost some money today on a bet with a colleague arguing that the following Java code was just plain invalid.

if( this_thing == DING & that_thing == DONG ) {
thenGoDoTheOtherThing();
}

Fortunately, he did not take me up on the bet! Turns out, for both Java and C#, when the & operator is used in this context the compiler stops treating it as the bitwise AND operator. Instead it treats it like the logical AND operator (&&) except that it applies a slightly modified evaluation rule - where && stops evaluation as soon as it encounters the first expression that evaluates to false, & goes ahead and evaluates all the expressions regardless of what each component expression evaluates to. The logical AND still works as one might expect, just that all the component expressions are always evaluated. Here's an example:

class Program
{
static void Main(string[] args)
{
if (Eval1() & Eval2())
Console.WriteLine("Eval1() and Eval2() returned true.");
else
Console.WriteLine("Eval1() and/or Eval2() returned false.");
}
static bool Eval1()
{
    Console.WriteLine("Eval1");
    return false;
}

static bool Eval2()
{
    Console.WriteLine("Eval2");
    return true;
}
}

And here's the output you get.

Eval1
Eval2
Eval1() and/or Eval2() returned false.

Guess you learn something new everyday! I am not sure that using this feature is such a great idea though. Thoughts?

-- gleat http://blogorama.nerdworks.in[^] --

modified on Friday, December 4, 2009 3:31 PM

Lost User · modified on Friday, December 4, 2009 3:31 PM

IMO, that it doesn't do the short circuit evaluation means that it actually is a bitwise AND, between two bools, but that doesn't make it any less "bitwise" or "AND", a bool is just 0 or 1 with nicer names after all..

OriginalGriff · modified on Friday, December 4, 2009 3:31 PM

Fortunately it should only work if (as in your example) both the parameters are bool - as it then performs a bitwise AND of the two results. Hence why it evaluates both rather than stopping when one fails. It's still quite nasty though - I wonder if you can turn it off...

if ((dataTable.Rows != null) & (dataTable.Rows.Count > 0))
{
...
}

would throw exactly the exception you are testing to avoid!

No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones "Rumour has it that if you play Microsoft CDs backwards you will hear Satanic messages.Worse still, is that if you play them forwards they will install Windows"

Luc Pattyn · modified on Friday, December 4, 2009 3:31 PM

That is what the documentation says: "Binary & operators are predefined for the integral types and bool. For integral types, & computes the logical bitwise AND of its operands. For bool operands, & computes the logical AND of its operands; that is, the result is true if and only if both its operands are true. The & operator evaluates both operators regardless of the first one's value." And now you can go and test/read up on the | operator... :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

Rajasekharan Vengalil

Yes. It does still perform a bitwise AND of the 2 boolean operands. Here's the IL for the sample code:

L_0000: call bool ConsoleApplication1.Program::Eval1()
L_0005: call bool ConsoleApplication1.Program::Eval2()
L_000a: and // this does a bitwise AND and pushes result to eval stack
L_000b: brfalse.s L_0018 // transfers control to instr L_0018 if val is false, null or zero
L_000d: ldstr "Eval1() and Eval2() returned true."
L_0012: call void [mscorlib]System.Console::WriteLine(string)
L_0017: ret
L_0018: ldstr "Eval1() and/or Eval2() returned false."
L_001d: call void [mscorlib]System.Console::WriteLine(string)
L_0022: ret

And I agree, it does seem to be a fairly dangerous operator. I'd be surprised if somebody deliberately used it with this explicit intent - chances are, in a majority of the cases its occurrence is a typo - and something the compiler won't even alert you about. :~

-- gleat http://blogorama.nerdworks.in[^] --

Rajasekharan Vengalil

Yep, it does indeed still do a bitwise AND of the boolean operands. See my reply[^] to OriginalGriff[^]'s post below.

-- gleat http://blogorama.nerdworks.in[^] --

Lost User

Luc Pattyn wrote:

And now you can go and test/read up on the | operator...

What about ^ ? One of the most underestimated operators ever.. except in cryptography of course. On the other hand, I've never had to xor two bools together, I've only done it once and just for laughs :)

Luc Pattyn

XORing bools isn't very useful for two bools, as you could as well compare them for (in)equality; XORing multiple bools makes more sense, not too many application domains will ever need it though. However XOR is fundamentally different from AND and OR, as there is no ^^ operator, and no short-circuiting. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

Lost User

Luc Pattyn wrote:

However XOR is fundamentally different from AND and OR, as there is no ^^ operator, and no short-circuiting.

Well of course not, that would be impossible, the result always depends on both inputs :)

Luc Pattyn

Exactly, it isn't "destructive", it preserves the true (or false) probability, something AND and OR don't. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

Abhinav S · modified on Friday, December 4, 2009 3:31 PM

Just in the same way, we could use | or || for normal or "short circuit" OR.