Coffeehouse Thread

37 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Select Case behavior

Back to Forum: Coffeehouse
  • User profile image
    davewill

    Curious ... I've recently been doing some parsing of some old file structures and in the process put in a little trick I remembered using in the VB3-6 days.  Only it doesn't work in .NET 2.0 like that anymore.  That made me wonder if I really was remembering the past correctly (not exactly my strong suit!).

    In the VB3-6 days when MyVarWithNumber9InIt = 9 then it would go through both case statements for 9 in the select case block.  In .NET 2.0 it goes through the first case for 9 then jumps out.

    Select case MyVarWithNumber9InIt

    Case 1

    'do case 1 stuff

    Case 2

    'do case 2 stuff

    Case 9

    'do case 9 stuff

    Case 3

    'do case 3 stuff

    Case 9

    'do case stuff

    Case else

    End select

     

    Does anyone else remember this type of behavior from the past?  Did the same type of behavior exist in the past for the Switch statement in C or was this a "feature" of the VB3-6 runtime?

     

  • User profile image
    Bas

    I don't remember if it was C or VB specifically but there were definitely languages that allowed this. I'd say they got rid of it because it's also hugely error prone: you'd be looking at a case block thinking "It's setting all this stuff correctly, so why is it messed up later?" and miss the fact that there's a second case block for that case further down. Same reason they got rid of the fall through stuff and require a break or return at the end of each case.

  • User profile image
    CKurt

    If I am correct the order of execution of the cases in a switch statement is not defined by the spec because fall trough behavior (like in C and C++) is not permitted C# ( I'm not sure for VB).

    But I guess C# would just not compile since you have two cases checking against the same constant.

    So my guess would be when VB changed to VB.NET this change happened because fall trough behavior is not allowed anymore.

  • User profile image
    Blue Ink

    I don't recall, honestly, and I don't have a copy of VB to test it out. Anyway, the only documentation I could find seems to indicate that that was not the intended behavior anyway.

    As for C, no, it never behaved that way. C maps the case labels (which must be integer constants) in  jump tables and obviously throws a fit if one of the labels is duplicated.

    Just out of curiosity, I cannot figure out the advantage of using that particular artifact. Care to elaborate?

  • User profile image
    davewill

    @Blue Ink: It was mainly to make the code more maintainable.  Sometimes when parsing older documents they would start off with nice recordtypes but then later through some spec comittee it would end up with one of the recordtypes behaving in different ways depending on what recordtypes occurred prior to reaching it.

    The Case 9 would then contain another Select case for the different behaviors.

    The use of separate case statements kept the different logic more readable since they really were not related.  Purely a way to make the code more readable.

    EDIT: I should have noted that the reason they didn't create a new recordtype is because they didn't want to break the existing spec.  thus a shoehorn was introduced Smiley

  • User profile image
    kettch

    @davewill: I just tested in VB6, and it doesn't hit both cases.

  • User profile image
    spivonious

    ,kettch wrote

    @davewill: I just tested in VB6, and it doesn't hit both cases.

    Confirmed. The execution jumps out of the Select Case after the first matching case is hit and executed.

  • User profile image
    magicalclick

    Do you mean the BREAK; ?

    I know in C++, you can say,

    Case1:

    somehting1;

    Case2:

    somthing2; break;

    Because case1 doesn't have break, case1 will do both somthing1 and something2, then finally break; You cannot do this on C# for sure because you are required to have break;. But, basically that's the word. If you break, you break the entire switch statement, it wouldn't make sense to even see the second Case9 as it already break.

     

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    davewill

    Hmmm ... and I wasn't old enough to have enjoyed the 70's Smiley  <insert head scratch here/>

  • User profile image
    cbae

    One thing about the C# switch statement is that it allows you to have the same code execute for different cases by allowing the code to fall through cases that have no code contained therein:

                switch (x)
                {
                    case 0:
                        //do something 0
                        break;
                    case 1:
                        //fall through
                    case 2:
                        //fall through
                    case 4:
                        //do something 1, 2, or 4
                        break;
                    case 3:
                        // do something 3
                        break;
                    default:
                        // do something default
                        break;
                }

    I find this to be quite useful.

  • User profile image
    xgamer

    @cbae it's not c# specific, even vb.net supports a more readable select or option

    Select Case x     
       Case 0,1,2,3         
            Console.WriteLine("hit") 
    End Select

  • User profile image
    ScanIAm

    @xgamer:

    I recently came up against a _bug_ in VB.Net where this didn't seem to do what I wanted it to:

    Select Case X
        Case 1
        Case 2
        Case 3
            Consol.WriteLine("hit")
    End Select

    I spent far too much time trying to figure out why Console.WriteLine("hit") was skipped when X was 1.  Any moderately seasoned VB developer can probably figure out pretty quickly, but I'm from the C world...

    This worked much better:

    Select Case X
        Case 1,
        Case 2,
        Case 3
            Consol.WriteLine("hit")
    End Select

    I'll admit that VB.Net is a complete .Net language, but I'm a bit tired of tracking down stupid syntax bugs...

  • User profile image
    davewill

    This might be more readable for you.

    Select case X
      Case 1, 2, 3
        Console.WriteLine("hit")
      Case Else
        Console.WriteLine("nadda")
    End Select

  • User profile image
    Adam​Speight2008

    You could also shrink that down to a single case statement.

    Select Case X
    
    Case 1 To 3: Console.WriteLine("hit")
    
    End Select

  • User profile image
    spivonious

    @ScanIAm: Yep, Select Case is not switch, even though they have similar functionality.

  • User profile image
    Maddus Mattus

    I've seen Bart Desmet showing what switch case statements are like when you compile them to IL,. It's really funny!

    When you do;

    int i = 0;
    switch(i)
    {
    case 8:
    bla();
    break;
    case 9:
    bla9();
    break;
    }

    it actually compiles into;

    int i = 8;
    switch(i)
    {
    case 0:
    bla();
    break;
    case 1:
    bla9();
    break;
    }

    They also do all sorts optimizations for multiple ranges,.. Was really fun session!

    here it is; http://channel9.msdn.com/Events/DevDays/DevDays-2011-Netherlands/Devdays041

    man I love C9

  • User profile image
    ScanIAm

    @spivonious: add to that, the propensity for the previous developers to do this:

     

       Select Case True
        Case X = 1
        Case X = 2
        Case Else
             'Do Something HereEnd Select

    instead of

    If X <> 1 AndAlso X <> 2 Then
        'do something here
    End If

    I frikkin hate 'clever' code.

  • User profile image
    Adam​Speight2008

    It has its uses though.

    First one to be true in the following order, or fall through, (And it's inverse)

    Select Case True
    Case X Is GetType(Double)
    Case X Is GetType(Single)
    

     

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.