Visual Basic, OR question....

OR question....

Author	Message
Boden Larso #1 / 4	OR question.... This is odd. I come primarily from a C background, for which I believe this would work as I intended. The following statement generated a Type Mismatch error at runtime... (I'm re-entering this so there might be minor syntax errors...) If Not(IsNumeric(strTemp)) Or (m_intFilter <> Cint(strTemp)) Then ... Now, I would have thought if the first portion of this OR statement was TRUE, then the second half would not be executed, for it doesn't need to be. I can, however, see why a language might be designed to execute both portions of the OR statement regardless to avoid confusion (e.g. you expect a function to be called and it isn't...). I think VB evaluates both sides of the OR regardless of the first condition (unless I'm having a problem with IsNumeric()). If strTemp is empty, "", then the first part of this statement would be true...Not(False) = true. But I get an error on this line durning, I believe, the integer cast. So... Now C code will drop out of that conditional as soon as enough conditions are met such that it can guarantee a result (e.g. stops if first condition in an OR is TRUE or first condition in an AND is FALSE). What's the skinny here? I didn't bother checking for errors in that integer cast above because I assumed that the first condition of the OR statement would guarantee that there couldn't be an error. I could have also used an AND but what I was trying to do was avoid the longer alternative: If IsNumeric(whatever) then If (Cint(Whatever)) blah blah ...which I don't like nearly as much (in my particular case). Boden Larson Computer Systems Analyst SGM Biotech, Inc.
Sun, 18 Nov 2001 03:00:00 GMT

Neila Ness #2 / 4	OR question.... Yep, VB does NOT short circuit logical expressions. Neila Quote: >This is odd. I come primarily from a C background, for which I believe this >would work as I intended. >The following statement generated a Type Mismatch error at runtime... (I'm >re-entering this so there might be minor syntax errors...) >If Not(IsNumeric(strTemp)) Or (m_intFilter <> Cint(strTemp)) Then ... >Now, I would have thought if the first portion of this OR statement was >TRUE, then the second half would not be executed, for it doesn't need to be. >I can, however, see why a language might be designed to execute both >portions of the OR statement regardless to avoid confusion (e.g. you expect >a function to be called and it isn't...). >I think VB evaluates both sides of the OR regardless of the first condition >(unless I'm having a problem with IsNumeric()). If strTemp is empty, "", >then the first part of this statement would be true...Not(False) = true. >But I get an error on this line durning, I believe, the integer cast. >So... >Now C code will drop out of that conditional as soon as enough conditions >are met such that it can guarantee a result (e.g. stops if first condition >in an OR is TRUE or first condition in an AND is FALSE). >What's the skinny here? I didn't bother checking for errors in that integer >cast above because I assumed that the first condition of the OR statement >would guarantee that there couldn't be an error. I could have also used >an AND but what I was trying to do was avoid the longer alternative: >If IsNumeric(whatever) then > If (Cint(Whatever)) blah blah >...which I don't like nearly as much (in my particular case). >Boden Larson >Computer Systems Analyst >SGM Biotech, Inc.
Sun, 18 Nov 2001 03:00:00 GMT

Lee J. Wein #3 / 4	OR question.... You're correct on both suppositions. All flavors of Microsoft Basic evaluate the ENTIRE If statement, even if the first boolean expression (IsNumeric(strTemp)) makes the evaluation of the second expression unnecessary. You're also correct that it's the cast (CInt(strTemp)) that's causing the error. I don't know any way around it except to nest the two conditions. Lee Weiner weiner AT fuse DOT net http://home.fuse.net/lweiner Quote: >This is odd. I come primarily from a C background, for which I believe this >would work as I intended. >The following statement generated a Type Mismatch error at runtime... (I'm >re-entering this so there might be minor syntax errors...) >If Not(IsNumeric(strTemp)) Or (m_intFilter <> Cint(strTemp)) Then ... >Now, I would have thought if the first portion of this OR statement was >TRUE, then the second half would not be executed, for it doesn't need to be. >I can, however, see why a language might be designed to execute both >portions of the OR statement regardless to avoid confusion (e.g. you expect >a function to be called and it isn't...). >I think VB evaluates both sides of the OR regardless of the first condition >(unless I'm having a problem with IsNumeric()). If strTemp is empty, "", >then the first part of this statement would be true...Not(False) = true. >But I get an error on this line durning, I believe, the integer cast. >So... >Now C code will drop out of that conditional as soon as enough conditions >are met such that it can guarantee a result (e.g. stops if first condition >in an OR is TRUE or first condition in an AND is FALSE). >What's the skinny here? I didn't bother checking for errors in that integer >cast above because I assumed that the first condition of the OR statement >would guarantee that there couldn't be an error. I could have also used >an AND but what I was trying to do was avoid the longer alternative: >If IsNumeric(whatever) then > If (Cint(Whatever)) blah blah >....which I don't like nearly as much (in my particular case). >Boden Larson >Computer Systems Analyst >SGM Biotech, Inc.
Mon, 19 Nov 2001 03:00:00 GMT

Hila #4 / 4	OR question.... Why not use Cint(val(strTemp)) just an idea :) Quote: > This is odd. I come primarily from a C background, for which I believe this > would work as I intended. > The following statement generated a Type Mismatch error at runtime... (I'm > re-entering this so there might be minor syntax errors...) > If Not(IsNumeric(strTemp)) Or (m_intFilter <> Cint(strTemp)) Then ... > Now, I would have thought if the first portion of this OR statement was > TRUE, then the second half would not be executed, for it doesn't need to be. > I can, however, see why a language might be designed to execute both > portions of the OR statement regardless to avoid confusion (e.g. you expect > a function to be called and it isn't...). > I think VB evaluates both sides of the OR regardless of the first condition > (unless I'm having a problem with IsNumeric()). If strTemp is empty, "", > then the first part of this statement would be true...Not(False) = true. > But I get an error on this line durning, I believe, the integer cast. > So... > Now C code will drop out of that conditional as soon as enough conditions > are met such that it can guarantee a result (e.g. stops if first condition > in an OR is TRUE or first condition in an AND is FALSE). > What's the skinny here? I didn't bother checking for errors in that integer > cast above because I assumed that the first condition of the OR statement > would guarantee that there couldn't be an error. I could have also used > an AND but what I was trying to do was avoid the longer alternative: > If IsNumeric(whatever) then > If (Cint(Whatever)) blah blah > ...which I don't like nearly as much (in my particular case). > Boden Larson > Computer Systems Analyst > SGM Biotech, Inc.
Mon, 19 Nov 2001 03:00:00 GMT

Page 1 of 1

[ 4 post ]