how well do you know VB (part 2)

Posted Thu, Jul 20 2006 0:06 by bill
a few weeks ago, I posted a quiz about the syntax low < x < high, which really was a quiz about implicit casting of Booleans. Of course the great Dan Appleman  got that one right :)
That quiz stemmed from an earlier post, and raised some questions about values of Booleans in general.  I plan to post a long explanation, but first I thought I'd have some more fun with syntax quizzes  :) 
 
Given the following conditions:
 - Code is compiled with Strict On and Explicit On rules applied
 - two variables are declared as follows:
 
  Dim x As Boolean = SomeFunctionthatReturnsABoolean()
  Dim y As Boolean = True
 
Do all the following evaluate to the same If condition ?  We're not concerned over how they get there, but whether or not they all get to the same place.
 
(1) If x = y Then
 
(2) If x And y Then
 
(3) If x <> Not y Then
 
(4) If Boolean.Equals(x,y) Then
 
Remember, y is specified as being True in all these expressions.
Are they all the same, always ?
 
 
 
 
 
 
Filed under: , ,

Comments

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 9:25 AM by Geoff Appleby

Starting off with an easy one are we? :)

I was looking for a trick, given that this is a quiz - so I looked so hard for some trick that I started wondering about item 2.

Crap, I thought to myself, is it doing a boolean and or a bitwise and?

But then I realised that it didn't matter - the trick is that you made me think that there's a trick :)

In all four cases, given that y is always true, they'll all pass or fail in the exact same way.

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 9:36 AM by bill

hmmm, are you sure ? ;)

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 11:09 AM by Chris

They will all get to the same place when x = true


The only confusing/ticky one is #3. If x is true and "not y" making false, then x <> false.

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 11:10 AM by Geoff Appleby

Well, I can't come up with a scenario where they _wouldn't_ all do the same thing. :)

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 11:50 AM by bill

Geoff, That's why it's a quiz :P

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 11:52 AM by bill

Chris you'd be right if x true, but what about other possibilities ;)

to quote Holmes "when all other contingencies fail, whatever remains, however improbable, must be the truth"

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 12:23 PM by Jonathan Allen

Well, I can use C#'s unsafe block to shove a 10 into the return value of "SomeFunctionthatReturnsABoolean".

Console.WriteLine(x) 'true
Console.WriteLine(y) 'true
Console.WriteLine(x = y) 'false
Console.WriteLine(x And y) 'false
Console.WriteLine(x <> Not y) 'true
Console.WriteLine(Boolean.Equals(x, y)) 'false

The rest I understand, but I am really surprised that Boolean.Equals doesn't work correctly.

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 12:41 PM by Andreas Zenker

I was wondering which method(s) were going to compare true vs false vs the integer values and didn't want to 'cheat' and read the docs. Since any value other than 0 is 'true' you could have two values that are both 'true' but don't equal each other. The "<> Not" will return true in Jonathan's test because 10 <> 0, all the others seem to be comparing the integer values as well. So I guess all of them compare the integer values? With that being the case the <> test becomes much more forgiving in that all that is required is not to be equal to 0 instead of being equal to some other non-zero number.

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 1:01 PM by bill

Andrew:,

you don't need to use unsafe code. See my blog entry a couple of years ago for a safe way of hackign a boolean:
http://msmvps.com/blogs/bill/archive/2004/06/22/8730.aspx

# re: how well do you know VB (part 2)

Wednesday, July 19, 2006 1:18 PM by bill

Andreas, yes we are now getting close to the crux of the issue ;)
All the comparisons are in fact comparing integers on the stack, using intrinisc IL operations (Equals indirectly).  So of the coding practices:
If x = y Then is risky as it is looking for exact equality. Same goes for Boolean.Equals.
The If x <> Not y works, but it relies on y being True. This is because Vb compiles it comparing it to zero. If you change y to False, you'll still get True in places because x doesn't equal 0 ;)

So all of the syntaxes have faults.  The If x And y syntax is lacking because y when True is 1 on the stack.  If however it was -1, as in all bits set, then x And y would be a true bistate only expression, returning 0 (false) when x is 0 (false), and True, when x is any other value.

The point ?  Well it's part of why traditionally, a booelan on the stack was either 0 or -1 as it provided fool proof masks :)