Subtle Initialization Fun

Quick, what's going to happen in scenario #1 vs scenario #2:

Scenario #1:

For counter As Integer = 1 To 5

   Dim i As Integer

   i += 1

   MsgBox(i)

Next

Scenario #2

For counter As Integer = 1 To 5

   Dim i As Integer = 0

   i += 1

   MsgBox(i)

Next

This type of stuff is pretty subtle. I really wish option strict made you initialize your variables too. And while I'm at it, an Option ImNotAnIdiot that short cicuits And statements without needing the AndAlso statement.  That would be cool.

6 Comments

  • Cory, I think Phil's comment about AndAlso is that he understands short-circuiting and doesn't need to use VB's old non-short-circuiting semantics. At least that's how I read the post.



    If you come from a Java/C#/C++ world, you're used to And short-circuiting automatically, so it seems like extra typing to have to enter AndAlso. Of course, the reason AndAlso was used was to ease porting and provide that much more backwards compatibility, but it still would be nice to be able to do: Option MakeAndShortCircuiting (although being able to rewire the semantics of an operator via an Option statement would make for some frustrating bugs down the road! ;-)

  • But you also have to remember that And is also used as a bit-wise operator on integer values, so by default making it short-circuitable would break a lot of functionality.

  • Oh, I'm perfectly aware of how it is suposed to work. I just received an e-mail from someone who assumed that the lifetime of the variable would be at the block level because that's where they declared it. Therefor, the variable would be "recreated" each time through the loop in some magical way, or at minimum reset to the default value. After all, most books say in some way or another that when you declare the variable, it gets set to zero automatically. You are "declaring" it five times. Not really of course, but I could see where the mistake could be made so I thought I'd point it out.



    As for the And / AndAlso debate, I can't fathom writing code that would rely on the fact that VB doesn't short circuit and / or statements. And I'm sure that the compiler designers could figure out when And was being used as a logical operator or a bit-wise operator.



    Sometimes I just get frustrated with the language nuances in VB.NET that exist because people have been writing bad code, and VB.NET had to be backwards compatable to keep those few people happy. It just introduces MORE bad code. It would be like if IE 6 still supported the BLINK tag to keep old sites looking the same.

  • Ah... understand now about the declaration. Now your point makes sense.



    As for And / AndOr, here's an example:



    If a And b = 1 Then

    End If



    If a andAlso b = 1 Then

    End If



    These two statements are very different. The first will do a bitwise operation on a and b then see if it equals 1. The second one will check to see if a is true and if b = 1 is true.



    How would the compiler know that you wanted the function to work one way vs. the other?



    Also, for clarity, I would write the first example as:



    If (a and b) = 1 Then

    End If



    It's seems to be clearer to me...

  • "How would the compiler know that you wanted the function to work one way vs the other?":



    Simple. Strongly typed variables. It's been a while since my compiler construction class, and I'll be the first to admit I'm pretty ignorant of these topics, but the compiler should be able to determain boolean data vs integer data.



    In fact, with option strict on, and with a and b both integers, "If a And b = 1" won't even compile (cannot convert integer to boolean). You have to write it as "(a and b) = 1"



    BTW, your transpanel and label demos are pretty damn cool.

  • You are right about strongly typed, unfortunately, VB.NET is able to run in a mode where Option Strict can be turned off (personally I think that is a mistake making this something that can be turned off and on globally, should be granular). If the language was always strongly typed, I'd agree with you. As it is, even in the VB6 days, you'd get a little bit of wierdness using And all by it's little lonesome. Also, it was not short circuited. I personally wouldn't have a problem going the other direction, but I do understand the reasons why they went the way they did.



    So personally, I just got used to always using AndAlso and OrElse. Just had to get into the habit of doing so, now it's no big deal.



    Thanks for the complements on the TransControls project. The first article got a little bit of traffic, but I'm not sure if people have come back to see part two, which IMHO is where things are starting to come together and the screen shot is much more impressive.

Comments have been disabled for this content.