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?

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.

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?

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

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.

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.

            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.

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

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

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

Select Case X

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

End Select

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

   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.

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)

and thanks for bringing up the "AndAlso" operator .. which i had forgotten completely ...

9 hours ago,ScanIAm wrote

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

 

1 2 3 4 5

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

instead of

1 2 3

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

I frikkin hate 'clever' code.

I sometimes use a do { } while (false) "loop".

And = &

AndAlso = &&

13 hours ago,cbae wrote

*snip*

I sometimes use a do { } while (false) "loop".

If x is not 2 or 3

instead of

If x != 2 && x != 3?

where @x not in (2,3)

Public Module ExtsMethods
 <System.Runtime.CompilerServices.Extension()>Public Function [IsNot](ByVal Value As Integer, ParamArray Values() As Integer) As Boolean
  Return Not Values.Contains(Value)

End Function

End Module

If x.[IsNot](2,3) Then

FoxPro has a function called INLIST(), which works with various types, not just integer types.

My C# equivalent uses an extension method like Adam's, but uses a generic method to support multiple types like FoxPro's INLIST():

public static class ExtClass
{
    public static bool IsInList<T>(this T origval, params T[] searchlist)
    {
        return searchlist.Contains(origval);
    }
}

Speaking of "clever" code, I remember seeing VFP code like this:

FUNCTION ValidateAll(cSomething1, cSomething2, cSomething3)
RETURN !INLIST(.F., ValFunc1(cSomeValue), ValFunc2(cSomething2), ValFunc3(cSomething3))
ENDFUNC

Edit: False alarm. Apparently, my code sample combined with spinovious' code sample in the same post causes some rendering issues. 

if (!(x == 2 || x == 3))

12 hours ago,xgamer wrote

@spivonious: That's another area of problem when switching between languages as unlike C# in C/PHP/Python .. "&" operator is bit wise operator ... hence I normally use the generic C like operators in most of the languages following C like syntax viz. Java, PHP,  partly Python ...  here vb.net is easier as the confusion between operator is minimum due to its own unique syntax ...

Actually, for all practical purposes the semantics of & are the same in C and C#.

Not that it matters much; there shouldn't be a good reason to prefer & to the short-circuiting && when dealing with boolean values (and when there is, your code probably contains a problem waiting to happen).

4 hours ago,Blue Ink wrote

Not that it matters much; there shouldn't be a good reason to prefer & to the short-circuiting && when dealing with boolean values.

The boolean value could be result of a side effecting function. Or the evaluate of each takes a while. Why even evaluate the second argument if you don't need to?

7 hours ago,Blue Ink wrote

Not that it matters much; there shouldn't be a good reason to prefer & to the short-circuiting && when dealing with boolean values (and when there is, your code probably contains a problem waiting to happen).

Timing attacks on security functions Some functions should never exit early on failure - comparing hash values for example.

9 hours ago,Adam​Speight2008 wrote

*snip*

The boolean value could be result of a side effecting function. Or the evaluate of each takes a while. Why even evaluate the second argument if you don't need to?

That was my point exactly. By using & instead of &&, either you are wasting time, or your code relies on obscure side-effects. Neither is desirable, unless you are dealing with...

6 hours ago,blowdart wrote

*snip*

Timing attacks on security functions Some functions should never exit early on failure - comparing hash values for example.

This is a legitimate case where short-circuiting is undesirable, and that can also happen elsewhere (for instance, time sensitive code in firmware). Yet, in these cases I prefer not to rely on a subtle difference and express my intent more clearly. Maintenance happens.

1 day ago,blowdart wrote

*snip*

Timing attacks on security functions Some functions should never exit early on failure - comparing hash values for example.

Every time you write your own hash function a cryptographer somewhere cries.

@Blue Ink: If you're writing hardware code that is timing sensitive and writing it in something other than C or assembly, then you're doing it wrong.

1 hour ago,evildictait​or wrote

*snip*

Every time you write your own hash function a cryptographer somewhere cries.

 

@Blue Ink: If you're writing hardware code that is timing sensitive and writing it in something other than C or assembly, then you're doing it wrong.

Obviously. And using C would still expose you to the subtle difference between eager and short-circuit operators... unfortunately mine wasn't an academic example.

As for the other comment, I think the hash function has little to do with what blowdart was referring to. If you use a method that fails early (such as short-circuit evaluation, or even just memcmp) when comparing some secret value with another submitted by the attacker, you may be giving away how much of the submitted value is correct. It's the same as making a combination lock that emits a louder tick whenever you hit on a partial result.

In the end, someone may cry, but it won't necessarily be a cryptographer.

4 hours ago,evildictait​or wrote

*snip*

Every time you write your own hash function a cryptographer somewhere cries...

...and becomes so distraught that he kills a kitten.

10 hours ago,cbae wrote

*snip*

...and becomes so distraught that he kills a kitten.

Oh no, that's when you call hashing encryption ....