Coffeehouse Thread

37 posts

Select Case behavior

Back to Forum: Coffeehouse
  • xgamer

    @ScanIAm: Living in a Hybrid code world of  Vb.net, C#, VB6, PowerBuilder (Yes businesses still depend on the programs developed in them...), Php/Python and occasionally Java ... i understand your frustration when switching between projects and syntaxes .... trying to catch the obvious bug Perplexed

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

  • cbae

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

  • spivonious

    @xgamer:

    And = &

    AndAlso = &&

  • xgamer

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

  • ScanIAm

    ,cbae wrote

    *snip*

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

    Generic Forum Image

  • spivonious

    Is there any language that lets your write something like

    If x is not 2 or 3

    instead of

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

  • davewill

    @spivonious: T-SQL comes to mind.

    where @x not in (2,3)

  • Adam​Speight2008

    It not that hard to implement with an extension method. Note though IsNot is a keyword in vb.net, hence the square braces.

    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

  • cbae

    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

  • cbae

    Great. The code tag is broken again.

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

  • Frank Hileman

    @spivonious:

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

  • Blue Ink

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

  • Adam​Speight2008

    ,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?

  • blowdart

    ,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 Smiley Some functions should never exit early on failure - comparing hash values for example.

  • Blue Ink

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

    ,blowdart wrote

    *snip*

    Timing attacks on security functions Smiley 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.

  • evildictait​or

    ,blowdart wrote

    *snip*

    Timing attacks on security functions Smiley 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.

  • Blue Ink

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

  • cbae

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

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.