Select Case behavior

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?

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.

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?

@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

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

8 minutes ago,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.

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.

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

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.

@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

@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...

This might be more readable for you.

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

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

Select Case X

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

End Select

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

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

@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.

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)