The Daily WTF: Curious Perversions in Information Technology
Welcome to TDWTF Forums Sign in | Join | Help
in Search

If would be greater than For, if I knew what If or Greater Than were for

Last post 05-30-2012 9:01 AM by pkmnfrk. 42 replies.
Page 1 of 1 (43 items)
Sort Posts: Previous Next
  • 05-28-2012 12:14 PM

    If would be greater than For, if I knew what If or Greater Than were for

     I've got the lovely task of adding a feature to a piece of... umm... code that was left behind by one of the developers who is no longer with us. Slightly anonymized for readability.

    eyeball_scooper:

    ' Not allow out of range index
    For
    LoopIndex = IndexBeingViewed To DataTable.Rows.Count - 1

    DataRow = DataTable.Rows(LoopIndex)

    ' ... snip just some simple processing ...

    Exit For

    Next



    HardwareGeek:

    <blink> and you're dead!



    "Where is grumpy cat?"
    - Mozilla's MOST ADVANCED USER!
  • 05-28-2012 12:40 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Please enlighten me, because I honestly see no problem with that code.

    Besides, of course, the fact that it's VB

  • 05-28-2012 12:46 PM In reply to

    • Julia
    • Not Ranked
    • Joined on 01-10-2008
    • Posts 37

    Re: If would be greater than For, if I knew what If or Greater Than were for

    LegacyCrono:

    Please enlighten me, because I honestly see no problem with that code.

    Besides, of course, the fact that it's VB

    It only processes the first row then bombs out of the loop? Looks like the original author is using For/Next/Exit to do a bounds check on IndexBeingViewed.
  • 05-28-2012 12:52 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Julia:
    LegacyCrono:

    Please enlighten me, because I honestly see no problem with that code.

    Besides, of course, the fact that it's VB

    It only processes the first row then bombs out of the loop? Looks like the original author is using For/Next/Exit to do a bounds check on IndexBeingViewed.

    Ah, oops. I didn't noticed the EXIT FOR there.

  • 05-28-2012 12:52 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    LegacyCrono:
    Please enlighten me, because I honestly see no problem with that code.

    Seriously? You're ok using a For Loop to check to see if a single row is within bounds, process that single row, then exit. There's no better way of conditionally processing one row based on checking the bounds? Really? None?

    mildly acceptable:

    ' Not allow out of range index
    If
    IndexBeingViewed >= 0 AndAlso IndexBeingViewed < DataTable.Rows.Count

    DataRow = DataTable.Rows(IndexBeingViewed)

    ' ... snip just some simple processing ...

    End If

     

    Edit:

    LegacyCrono:
    Ah, oops. I didn't noticed the EXIT FOR there.

    You're forgiven. This time.


    Also, it's VB.

     


    HardwareGeek:

    <blink> and you're dead!



    "Where is grumpy cat?"
    - Mozilla's MOST ADVANCED USER!
  • 05-28-2012 1:43 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Lorne Kates:

    a piece of... umm... code that was left behind by one of the developers who is no longer with us.

    Deceased? </hopeful>

     

  • 05-28-2012 1:50 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    DaveK:

    Lorne Kates:

    a piece of... umm... code that was left behind by one of the developers who is no longer with us.

    Deceased? </hopeful>

     

    I'd need a shovel and a cement pick to know for sure.

     


    HardwareGeek:

    <blink> and you're dead!



    "Where is grumpy cat?"
    - Mozilla's MOST ADVANCED USER!
  • 05-28-2012 4:19 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Lorne Kates:

     I've got the lovely task of adding a feature to a piece of... umm... code that was left behind by one of the developers who is no longer with us. Slightly anonymized for readability.

    eyeball_scooper:

    ' Not allow out of range index
    For
    LoopIndex = IndexBeingViewed To DataTable.Rows.Count - 1

    DataRow = DataTable.Rows(LoopIndex)

    ' ... snip just some simple processing ...

    Exit For

    Next


    It's an "elegant" way to do a IF...



    2,993 people like this.
  • 05-28-2012 6:45 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Lorne Kates:

    DaveK:

    Lorne Kates:

    a piece of... umm... code that was left behind by one of the developers who is no longer with us.

    Deceased? </hopeful>

     

    I'd need a shovel and a cement pick to know for sure.

    You should have left him in there with a tube of a cyanide, a radium atom and a Geiger counter.

    Let the healing begin!

  • I may not agree with everything Morbs just said, but he expresses himself in a way that is dignified, respectful, polite and non-threatening!
  • 05-28-2012 9:17 PM In reply to

    • emurphy
    • Top 100 Contributor
    • Joined on 01-14-2005
    • Granada Hills, CA
    • Posts 576

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Lorne Kates:

    ' Not allow out of range index
    If
    IndexBeingViewed >= 0 AndAlso IndexBeingViewed < DataTable.Rows.Count

    DataRow = DataTable.Rows(IndexBeingViewed)

    ' ... snip just some simple processing ...

    End If

     

     

    But you've changed the original "crashes when IndexBeingViewed < 0" behavior! </sarcasm>

     

     

  • 05-29-2012 7:13 AM In reply to

    • Crect
    • Not Ranked
    • Joined on 02-23-2012
    • Posts 5

    Re: If would be greater than For, if I knew what If or Greater Than were for

     Still needs a try catch block, just in case......

  • 05-29-2012 7:24 AM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Lorne Kates:
    AndAlso
    No language bashing intended (moreover it's just too easy to bash VB...) but.... seriously. Stop that please.

    Ionian peculiar of Pervertiti in the technology of the process of the data
  • 05-29-2012 7:31 AM In reply to

    • PJH
    • Top 10 Contributor
    • Joined on 02-14-2007
    • Newcastle, UK
    • Posts 3,916

    Re: If would be greater than For, if I knew what If or Greater Than were for

    toshir0:

    Lorne Kates:
    AndAlso
    No language bashing intended (moreover it's just too easy to bash VB...) but.... seriously. Stop that please.

    OrElse what....?
    "Because you watched 'The Very Hungry Caterpillar,' we recommend 'The Human Centipede.'"
    --
    UED - Countryside: To kill Piers Morgan
  • Parp!
  • 05-29-2012 8:23 AM In reply to

    • KattMan
    • Top 75 Contributor
    • Joined on 10-18-2006
    • Location Unknown, Destination Anywhere
    • Posts 662

    Re: If would be greater than For, if I knew what If or Greater Than were for

    LegacyCrono:
    Julia:
    LegacyCrono:

    Please enlighten me, because I honestly see no problem with that code.

    Besides, of course, the fact that it's VB

    It only processes the first row then bombs out of the loop? Looks like the original author is using For/Next/Exit to do a bounds check on IndexBeingViewed.

    Ah, oops. I didn't noticed the EXIT FOR there.

    Obviously even VB is to difficult for you to read the logic in a paltry 4 lines of code.  In this case, VB is NOT the problem, that thing in the mirror is.

     

    CAPTCHA? We ain't got no CAPTCHA. We don't need no CAPTCHA. We don't need no stinking CAPTCHA!
  • 05-29-2012 8:35 AM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    toshir0:

    Lorne Kates:
    AndAlso
    No language bashing intended (moreover it's just too easy to bash VB...) but.... seriously. Stop that please.

     

    I wish I could, but that's the only way to short circuit a logic check in VB (because somewhere, someone thought that would be a good idea)

    If foo IsNot Nothing And foo.bar() Then ' <======= This crashes on null foo
    If foo IsNot Nothing AndAlso foo.bar() Then ' <==== This stops at the AndAlso

     

     


    HardwareGeek:

    <blink> and you're dead!



    "Where is grumpy cat?"
    - Mozilla's MOST ADVANCED USER!
  • 05-29-2012 8:38 AM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    morbiuswilters:
    You should have left him in there with a tube of a cyanide, a radium atom and a Geiger counter.
     

    I did, except instead of cyanide, it's a tube marked "Early Release". It's a laxative.

    And instead of a Geiger counter, I cheaped out and bought a Gaga counter. It's an MP3 player with a nuclear power source that plays nothing but a constant loop of ABBA's greatest hits. I don't know why they called it "Gaga". But that's what you get from dollar store made-in-China torture devices.

    I was going to put in a radium atom, but my cat ate it. I think.


    HardwareGeek:

    <blink> and you're dead!



    "Where is grumpy cat?"
    - Mozilla's MOST ADVANCED USER!
  • 05-29-2012 8:55 AM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Lorne Kates:

    toshir0:

    Lorne Kates:
    AndAlso
    No language bashing intended (moreover it's just too easy to bash VB...) but.... seriously. Stop that please.

     

    I wish I could, but that's the only way to short circuit a logic check in VB (because somewhere, someone thought that would be a good idea)

    If foo IsNot Nothing And foo.bar() Then ' <======= This crashes on null foo
    If foo IsNot Nothing AndAlso foo.bar() Then ' <==== This stops at the AndAlso

    OK, thank you for the explanation (if I get it well, the second form being equivalent to the '&&' we can find in many other places, like, say, javascript), I'm almost VB-virgin. Not that I resent that, though.

    Lorne Kates:
    my cat ate it
    Not him.

    *pukes pink goo*

    Ionian peculiar of Pervertiti in the technology of the process of the data
  • 05-29-2012 9:43 AM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Lorne Kates:

    mildly acceptable:

    ' Not allow out of range index
    If
    IndexBeingViewed >= 0 AndAlso IndexBeingViewed < DataTable.Rows.Count

    In VB.NET, maybe. But the AndAlso operator doesn't exist in VB6.
  • 05-29-2012 9:44 AM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    toshir0:

    Lorne Kates:
    my cat ate it
    Not him.

    *pukes pink goo*

     

    From a single atom?

     


    In complex analysis, a meromorphic function on an open subset D of the complex plane is a function that is holomorphic on all D except a set of isolated points

  • 05-29-2012 9:49 AM In reply to

    • ekolis
    • Top 100 Contributor
    • Joined on 01-09-2008
    • Cincinnati, OH, USA
    • Posts 600

    Re: If would be greater than For, if I knew what If or Greater Than were for

    toshir0:

    Lorne Kates:
    AndAlso
    No language bashing intended (moreover it's just too easy to bash VB...) but.... seriously. Stop that please.

    Yeah, you should know that in the latest version of VB, it's AndWithYourSpirit...
    I'm Spark Mandrill, and I'll... hey... can I... what, it BOUNCES?... 'kay, I'm splodin' now.
  • 05-29-2012 9:50 AM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    dhromed:
    From a single atom?
    Why ? Are married atoms safer ?

    Ionian peculiar of Pervertiti in the technology of the process of the data
  • 05-29-2012 12:26 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    dhromed:

    toshir0:

    Lorne Kates:
    my cat ate it
    Not him.

    *pukes pink goo*

     

    From a single atom?

    I dunno.. radium atoms are pretty big. This isn't helium we're talking about.

    Let the healing begin!

  • I may not agree with everything Morbs just said, but he expresses himself in a way that is dignified, respectful, polite and non-threatening!
  • 05-29-2012 12:47 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    toshir0:
    Lorne Kates:
    toshir0:

    Lorne Kates:
    AndAlso
    No language bashing intended (moreover it's just too easy to bash VB...) but.... seriously. Stop that please.
     

    I wish I could, but that's the only way to short circuit a logic check in VB (because somewhere, someone thought that would be a good idea)

    If foo IsNot Nothing And foo.bar() Then ' <======= This crashes on null foo
    If foo IsNot Nothing AndAlso foo.bar() Then ' <==== This stops at the AndAlso

    OK, thank you for the explanation (if I get it well, the second form being equivalent to the '&&' we can find in many other places, like, say, javascript), I'm almost VB-virgin. Not that I resent that, though.
     

    Yup.  And JavaScript got it from C, and C needed the whole ridiculous "two AND and two OR operators" thing because its type system is too weak for the compiler to tell the difference between a number and a boolean.  VB does not have that problem (and neither do Java or C#) but they've all mindlessly copied the broken, ugly C model just because that's the way C does it so it must be right.

    And since the whole boolean vs. number issue isn't an issue in a language with a halfway decent type system, they've changed the rationale for it to instead be about a side-effect of the original C behavior: one of them short-circuits on logical operations (because it's a logical operator) and one does not (because it's it originally was a bitwise operator whose arguments are two integers and should never be used for logical operations.)  Which is even stupider than the original.  If your code intentionally uses a non-short-circuiting conditional for any reason, you're doing something very wrong and need to refactor.

    Gotta love C-argo C-ult language design...

  • 05-29-2012 1:04 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:

    Yup.  And JavaScript got it from C, and C needed the whole ridiculous "two AND and two OR operators" thing because its type system is too weak for the compiler to tell the difference between a number and a boolean.  VB does not have that problem (and neither do Java or C#) but they've all mindlessly copied the broken, ugly C model just because that's the way C does it so it must be right.

    And since the whole boolean vs. number issue isn't an issue in a language with a halfway decent type system, they've changed the rationale for it to instead be about a side-effect of the original C behavior: one of them short-circuits on logical operations (because it's a logical operator) and one does not (because it's it originally was a bitwise operator whose arguments are two integers and should never be used for logical operations.)  Which is even stupider than the original.  If your code intentionally uses a non-short-circuiting conditional for any reason, you're doing something very wrong and need to refactor.

    Gotta love C-argo C-ult language design...

    [citation needed] C originally lacked booleans, all logical operations were done on integers. It didn't need to distinguish between numbers and booleans.

    It's true languages like Java could have done without two sets of AND and OR operators, but it was likely retained to make the transition from C easier. I would consider it a pretty minor bit of overhead and not really worth complaining about.

    I do agree that non-short-circuiting conditionals are a WTF.

    Let the healing begin!

  • I may not agree with everything Morbs just said, but he expresses himself in a way that is dignified, respectful, polite and non-threatening!
  • 05-29-2012 1:05 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:

    toshir0:
    Lorne Kates:
    toshir0:

    Lorne Kates:
    AndAlso
    No language bashing intended (moreover it's just too easy to bash VB...) but.... seriously. Stop that please.
     

    I wish I could, but that's the only way to short circuit a logic check in VB (because somewhere, someone thought that would be a good idea)

    If foo IsNot Nothing And foo.bar() Then ' <======= This crashes on null foo
    If foo IsNot Nothing AndAlso foo.bar() Then ' <==== This stops at the AndAlso

    OK, thank you for the explanation (if I get it well, the second form being equivalent to the '&&' we can find in many other places, like, say, javascript), I'm almost VB-virgin. Not that I resent that, though.
     

    Yup.  And JavaScript got it from C, and C needed the whole ridiculous "two AND and two OR operators" thing because its type system is too weak for the compiler to tell the difference between a number and a boolean.  VB does not have that problem (and neither do Java or C#) but they've all mindlessly copied the broken, ugly C model just because that's the way C does it so it must be right.

    And since the whole boolean vs. number issue isn't an issue in a language with a halfway decent type system, they've changed the rationale for it to instead be about a side-effect of the original C behavior: one of them short-circuits on logical operations (because it's a logical operator) and one does not (because it's it originally was a bitwise operator whose arguments are two integers and should never be used for logical operations.)  Which is even stupider than the original.  If your code intentionally uses a non-short-circuiting conditional for any reason, you're doing something very wrong and need to refactor.

    Gotta love C-argo C-ult language design...

    If you enjoy good design try to use the IIF(condition,value_if_true, value_if_false) function in Microsoft Reporting Services to avoid a divide by zero error... Unlike the IF construct, that function evaluates all parameters no matter what.

    iif(BottomValue=0,0,TopValue/BottomValue) //divide by zero error is BottomValue is 0
    iif(BottomValue=0,0,TopValue/iif(BottomValue=0,1,BottomValue)) //works


    2,993 people like this.
  • 05-29-2012 1:07 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:
    Yup.  And JavaScript got it from C, and C needed the whole ridiculous "two AND and two OR operators" thing because its type system is too weak for the compiler to tell the difference between a number and a boolean.  VB does not have that problem (and neither do Java or C#) but they've all mindlessly copied the broken, ugly C model just because that's the way C does it so it must be right.
    TDEMSYR. Seriously, WTF are you talking about here?
    I denounce myself for this post
  • 05-29-2012 1:24 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    boomzilla:
    Mason Wheeler:
    Yup.  And JavaScript got it from C, and C needed the whole ridiculous "two AND and two OR operators" thing because its type system is too weak for the compiler to tell the difference between a number and a boolean.  VB does not have that problem (and neither do Java or C#) but they've all mindlessly copied the broken, ugly C model just because that's the way C does it so it must be right.
    TDEMSYR. Seriously, WTF are you talking about here?
     

    I'm talking about history.  As Morbs pointed out, there was no Boolean type in C.  Instead, the rule was "everything is a boolean."  Integers, pointers, floating-point numbers, anything could represent False (if 0/null) or True (if any other value.)  So because there's no Boolean type, the compiler can't do something sensible like what a Pascal compiler (invented before C, and got it right) can do:

    myBool3 := myBool1 and myBool2; //Both arguments are booleans, so this is a logical AND
    myInt3 := myInt1 and myInt2; //both arguments are integers, so this is a bitwise AND
    myError := myBool1 and myInt2; //compiler error. This operation makes no sense. (But you can still do it in C...)
    Instead, you have to do the compiler's work for it by selecting between two different versions of the operators, and heaven help you if you accidentally pick the wrong one, because the compiler's not going to.  (And for some reason that kindasorta makes sense at the bits and bytes level, but not from a consistency perspective, there's only one XOR operator.  And the bitwise and logical NOT operators are two different symbols instead of one symbol that's either used once or twice.  Go figure.)

     

  • 05-29-2012 1:34 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:

    boomzilla:
    Mason Wheeler:
    Yup.  And JavaScript got it from C, and C needed the whole ridiculous "two AND and two OR operators" thing because its type system is too weak for the compiler to tell the difference between a number and a boolean.  VB does not have that problem (and neither do Java or C#) but they've all mindlessly copied the broken, ugly C model just because that's the way C does it so it must be right.
    TDEMSYR. Seriously, WTF are you talking about here?
     

    I'm talking about history.  As Morbs pointed out, there was no Boolean type in C.  Instead, the rule was "everything is a boolean."  Integers, pointers, floating-point numbers, anything could represent False (if 0/null) or True (if any other value.)  So because there's no Boolean type, the compiler can't do something sensible like what a Pascal compiler (invented before C, and got it right) can do:

    myBool3 := myBool1 and myBool2; //Both arguments are booleans, so this is a logical AND
    myInt3 := myInt1 and myInt2; //both arguments are integers, so this is a bitwise AND
    myError := myBool1 and myInt2; //compiler error. This operation makes no sense. (But you can still do it in C...)
    Instead, you have to do the compiler's work for it by selecting between two different versions of the operators, and heaven help you if you accidentally pick the wrong one, because the compiler's not going to.  (And for some reason that kindasorta makes sense at the bits and bytes level, but not from a consistency perspective, there's only one XOR operator.  And the bitwise and logical NOT operators are two different symbols instead of one symbol that's either used once or twice.  Go figure.)

     

    This is incorrect. According to Dennis Ritchie, C originally only had the "bitwise" & and | operators, which did short-circuiting in a boolean truth context (e.g. in a while or if statement). However, the implicit difference in behavior based on context was considered confusing, so they re-jiggered it to have additional "logical" operators which made the semantics explicit.

    Let the healing begin!

  • I may not agree with everything Morbs just said, but he expresses himself in a way that is dignified, respectful, polite and non-threatening!
  • 05-29-2012 1:37 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:

    boomzilla:
    Mason Wheeler:
    Yup.  And JavaScript got it from C, and C needed the whole ridiculous "two AND and two OR operators" thing because its type system is too weak for the compiler to tell the difference between a number and a boolean.  VB does not have that problem (and neither do Java or C#) but they've all mindlessly copied the broken, ugly C model just because that's the way C does it so it must be right.
    TDEMSYR. Seriously, WTF are you talking about here?

    I'm talking about history.  As Morbs pointed out, there was no Boolean type in C.  Instead, the rule was "everything is a boolean."  Integers, pointers, floating-point numbers, anything could represent False (if 0/null) or True (if any other value.)  So because there's no Boolean type, the compiler can't do something sensible like what a Pascal compiler (invented before C, and got it right) can do:

    myBool3 := myBool1 and myBool2; //Both arguments are booleans, so this is a logical AND
    myInt3 := myInt1 and myInt2; //both arguments are integers, so this is a bitwise AND
    myError := myBool1 and myInt2; //compiler error. This operation makes no sense. (But you can still do it in C...)
    Instead, you have to do the compiler's work for it by selecting between two different versions of the operators, and heaven help you if you accidentally pick the wrong one, because the compiler's not going to.  (And for some reason that kindasorta makes sense at the bits and bytes level, but not from a consistency perspective, there's only one XOR operator.  And the bitwise and logical NOT operators are two different symbols instead of one symbol that's either used once or twice.  Go figure.)
    Strongly typed if statements annoy me, though they do allow the compiler to catch stuff where you're assigning inside the if condition (of course, the proper way to stop that is to not allow assignments inside there). TRWTF is how you got here from talking about short circuiting, which is probably what confused me. I mean, don't let me stop you from your favorite rant or anything...the non sequitur just threw me a bit.
    I denounce myself for this post
  • 05-29-2012 1:57 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    morbiuswilters:
    This is incorrect. According to Dennis Ritchie, C originally only had the "bitwise" & and | operators, which did short-circuiting in a boolean truth context (e.g. in a while or if statement). However, the implicit difference in behavior based on context was considered confusing, so they re-jiggered it to have additional "logical" operators which made the semantics explicit.
     

    Interesting.  I hadn't heard that before.  Do you have a source for that?  And how long did that last before they made the change?  Because as far back as I can remember, there have been double AND and OR operators in C...

     

  • 05-29-2012 2:02 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    boomzilla:
    Strongly typed if statements annoy me, though they do allow the compiler to catch stuff where you're assigning inside the if condition

    Who said anything about "strongly typed if statements," or if statements in general?  I was talking about AND and OR operators.  They can be used in conditionals, but that's hardly the only thing that can be done with them. (See my example code, where they're used to assign to another value.)

    (of course, the proper way to stop that is to not allow assignments inside there).

    The proper way to do that is to not allow the bloody assignment operator to return a value, whether you're in a conditional or not.

    TRWTF is how you got here from talking about short circuiting, which is probably what confused me. I mean, don't let me stop you from your favorite rant or anything...the non sequitur just threw me a bit.
     

    By way of toshir0's observation that the VB operator strangeness was mirroring similar strangeness in Javascript and "other languages".  I just happened to know where the root of all that was.

     

  • 05-29-2012 2:08 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:

    morbiuswilters:
    This is incorrect. According to Dennis Ritchie, C originally only had the "bitwise" & and | operators, which did short-circuiting in a boolean truth context (e.g. in a while or if statement). However, the implicit difference in behavior based on context was considered confusing, so they re-jiggered it to have additional "logical" operators which made the semantics explicit.
     

    Interesting.  I hadn't heard that before.  Do you have a source for that?  And how long did that last before they made the change?  Because as far back as I can remember, there have been double AND and OR operators in C...

     

    Here's the best I could find: http://www.lysator.liu.se/c/dmr-on-or.html From the sound of it, it was implemented before K&R was even written.

    Let the healing begin!

  • I may not agree with everything Morbs just said, but he expresses himself in a way that is dignified, respectful, polite and non-threatening!
  • 05-29-2012 2:15 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:
    The proper way to do that is to not allow the bloody assignment operator to return a value, whether you're in a conditional or not.

    Do you mean that you are also against this?

    x = y = 1

    I always found this convenient, just like methods chaining (such as DateTime.AddDays(x).ToString()). But I have to say I care more about convenience than principles, unless the principles serve me better (which is then a form of convenience anyways).



    2,993 people like this.
  • 05-29-2012 2:15 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:
    I was talking about AND and OR operators.  They can be used in conditionals, but that's hardly the only thing that can be done with them. (See my example code, where they're used to assign to another value.)
    So the deficiency of C is that it can't use a single operator to do short-circuiting AND/OR in a boolean assignment because it's no different than doing a bitwise AND/OR, since there is no boolean type in C. However, it could do it in a "truth context", which is where most people would use it. However, C long-ago rectified this by adding additional logical operator to do short-circuiting boolean operations. I don't consider this a big deal. Nor do I consider it a big deal that other languages inherited C's semantics, most likely as a way to make the transition for C programmers easier.

    Mason Wheeler:
    The proper way to do that is to not allow the bloody assignment operator to return a value, whether you're in a conditional or not.
    110% agreed.

    Let the healing begin!

  • I may not agree with everything Morbs just said, but he expresses himself in a way that is dignified, respectful, polite and non-threatening!
  • 05-29-2012 2:17 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Speakerphone Dude:
    Mason Wheeler:
    The proper way to do that is to not allow the bloody assignment operator to return a value, whether you're in a conditional or not.

    Do you mean that you are also against this?

    x = y = 1

    I always found this convenient, just like methods chaining (such as DateTime.AddDays(x).ToString()). But I have to say I care more about convenience than principles, unless the principles serve me better (which is then a form of convenience anyways).

    I think that's less clear than:

    y = 1;
    x = y;

    Clarity is key to maintainability and reducing the number of bugs. Whatever short-term convenience there is in allowing chained assignments is significantly overshadowed by all of the problems it has introduced.

    Let the healing begin!

  • I may not agree with everything Morbs just said, but he expresses himself in a way that is dignified, respectful, polite and non-threatening!
  • 05-29-2012 2:34 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:
    boomzilla:
    Strongly typed if statements annoy me, though they do allow the compiler to catch stuff where you're assigning inside the if condition
    Who said anything about "strongly typed if statements," or if statements in general?  I was talking about AND and OR operators.  They can be used in conditionals, but that's hardly the only thing that can be done with them. (See my example code, where they're used to assign to another value.)
    Well, you talked about how C doesn't have a boolean type, which is kinda required for strongly typed if statements. Using integers as boolean stand-ins has never bothered me.
    Mason Wheeler:
    boomzilla:
    (of course, the proper way to stop that is to not allow assignments inside there).

    The proper way to do that is to not allow the bloody assignment operator to return a value, whether you're in a conditional or not.

    That's quite a bit broader that the topic at hand, but that construct always seems to lead to clever code, and I wouldn't mind not having that, but it's not on the same level as allowing assignments inside of a comparison.
    Mason Wheeler:
    TRWTF is how you got here from talking about short circuiting, which is probably what confused me. I mean, don't let me stop you from your favorite rant or anything...the non sequitur just threw me a bit.
    By way of toshir0's observation that the VB operator strangeness was mirroring similar strangeness in Javascript and "other languages".  I just happened to know where the root of all that was.
    Yeah, except that it was pretty orthogonal (maybe tangential, at best) to short circuiting.
    I denounce myself for this post
  • 05-29-2012 2:41 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    morbiuswilters:
    Speakerphone Dude:
    Mason Wheeler:
    The proper way to do that is to not allow the bloody assignment operator to return a value, whether you're in a conditional or not.

    Do you mean that you are also against this?

    x = y = 1

    I always found this convenient, just like methods chaining (such as DateTime.AddDays(x).ToString()). But I have to say I care more about convenience than principles, unless the principles serve me better (which is then a form of convenience anyways).

    I think that's less clear than:

    y = 1;
    x = y;

    Clarity is key to maintainability and reducing the number of bugs. Whatever short-term convenience there is in allowing chained assignments is significantly overshadowed by all of the problems it has introduced.
     

    This.  Plus, the concept just makes me vaguely uncomfortable.  I can't really articulate why very well, but I sort of have the feeling that if you're initializing two variables to the same value, one immediately after the other like that (and that value is not zero/null/other "empty value") then you're probably doing something wrong, or at least there's a better way to accomplish whatever it is you're doing.

     

  • 05-29-2012 2:48 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:

    morbiuswilters:
    Speakerphone Dude:
    Mason Wheeler:
    The proper way to do that is to not allow the bloody assignment operator to return a value, whether you're in a conditional or not.

    Do you mean that you are also against this?

    x = y = 1

    I always found this convenient, just like methods chaining (such as DateTime.AddDays(x).ToString()). But I have to say I care more about convenience than principles, unless the principles serve me better (which is then a form of convenience anyways).

    I think that's less clear than:

    y = 1;
    x = y;

    Clarity is key to maintainability and reducing the number of bugs. Whatever short-term convenience there is in allowing chained assignments is significantly overshadowed by all of the problems it has introduced.
     

    This.  Plus, the concept just makes me vaguely uncomfortable.  I can't really articulate why very well, but I sort of have the feeling that if you're initializing two variables to the same value, one immediately after the other like that (and that value is not zero/null/other "empty value") then you're probably doing something wrong, or at least there's a better way to accomplish whatever it is you're doing.

     

    Basically agree. I can think of contrived examples where you would want to start two variables at the same value because one is going to quickly diverge (e.g. a startIndex and currentIndex value for a vector just before a loop which will increment currentIndex), but in those cases it's still fine to just explicitly have two assignments on their own lines instead of a single chained assignment. The cost of getting rid of chained assignments is very small and the potential benefits are large.

    Let the healing begin!

  • I may not agree with everything Morbs just said, but he expresses himself in a way that is dignified, respectful, polite and non-threatening!
  • 05-29-2012 3:06 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Speakerphone Dude:

    Do you mean that you are also against this?

    x = y = 1

    I've got no problem with it in PL/1, except that to avoid confusion it should be written:

     x = (y = 1);

    and anyone not trying to be cute will probably write it as:

    if y=1 then x = '1'b; else x = '0'b;

    (Oh, and we had your AndAlso as well.  It's called Then If.)

     

  • 05-29-2012 3:46 PM In reply to

    • Gurrag
    • Not Ranked
    • Joined on 05-29-2012
    • Posts 1

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:
    there's only one XOR operator.

     

    !=

    EDIT:  I'm way off on that one, != won't properly logical-XOR two "True" yet different values, i.e. 1 and 2.

  • 05-29-2012 4:21 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Just for added confusion (as far as I can tell), Perl allows

    ($x = $y) = 1;

    which assigns $y to $x, then 1 to $x.

    I can't think of any reason why you'd actually want to do that, but hey, the option is there!

  • 05-29-2012 4:34 PM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Mason Wheeler:

    morbiuswilters:
    Speakerphone Dude:
    Mason Wheeler:
    The proper way to do that is to not allow the bloody assignment operator to return a value, whether you're in a conditional or not.

    Do you mean that you are also against this?

    x = y = 1

    I always found this convenient, just like methods chaining (such as DateTime.AddDays(x).ToString()). But I have to say I care more about convenience than principles, unless the principles serve me better (which is then a form of convenience anyways).

    I think that's less clear than:

    y = 1;
    x = y;

    Clarity is key to maintainability and reducing the number of bugs. Whatever short-term convenience there is in allowing chained assignments is significantly overshadowed by all of the problems it has introduced.
     

    This.  Plus, the concept just makes me vaguely uncomfortable.  I can't really articulate why very well, but I sort of have the feeling that if you're initializing two variables to the same value, one immediately after the other like that (and that value is not zero/null/other "empty value") then you're probably doing something wrong, or at least there's a better way to accomplish whatever it is you're doing.

     

    That was a simplified syntax example. One could meet a situation where the output value of a method can be used to chain updates on properties for objects that need the same information without running the method twice.

    Here is an example in manufacturing where distinct areas of the supply chain need to be kept in sync.

    /*short notation*/
    AVCO.PurchasedTotal = ERP.O2C = GL.Consolidate(item);

    /*long notation*/
    ERP.O2C = GL.Consolidate(item);
    AVCO.PurchasedTotal = ERP.O2C;

    IMHO the long notation does not convey the same visual logic that all those values are related, and this is the nature of the business to have some kind of multicasting on the source value. I see nothing wrong with the short notation but it's not something I would refactor one way or the other if I had to maintain some code anyways. Maybe it's just me.



    2,993 people like this.
  • 05-30-2012 9:01 AM In reply to

    Re: If would be greater than For, if I knew what If or Greater Than were for

    Speakerphone Dude:
    Mason Wheeler:

    morbiuswilters:
    Speakerphone Dude:
    Mason Wheeler:
    The proper way to do that is to not allow the bloody assignment operator to return a value, whether you're in a conditional or not.

    Do you mean that you are also against this?

    x = y = 1

    I always found this convenient, just like methods chaining (such as DateTime.AddDays(x).ToString()). But I have to say I care more about convenience than principles, unless the principles serve me better (which is then a form of convenience anyways).

    I think that's less clear than:

    y = 1;
    x = y;

    Clarity is key to maintainability and reducing the number of bugs. Whatever short-term convenience there is in allowing chained assignments is significantly overshadowed by all of the problems it has introduced.
     

    This.  Plus, the concept just makes me vaguely uncomfortable.  I can't really articulate why very well, but I sort of have the feeling that if you're initializing two variables to the same value, one immediately after the other like that (and that value is not zero/null/other "empty value") then you're probably doing something wrong, or at least there's a better way to accomplish whatever it is you're doing.

     

    That was a simplified syntax example. One could meet a situation where the output value of a method can be used to chain updates on properties for objects that need the same information without running the method twice.

    Here is an example in manufacturing where distinct areas of the supply chain need to be kept in sync.

    /*short notation*/
    AVCO.PurchasedTotal = ERP.O2C = GL.Consolidate(item);

    /*long notation*/
    ERP.O2C = GL.Consolidate(item);
    AVCO.PurchasedTotal = ERP.O2C;

    IMHO the long notation does not convey the same visual logic that all those values are related, and this is the nature of the business to have some kind of multicasting on the source value. I see nothing wrong with the short notation but it's not something I would refactor one way or the other if I had to maintain some code anyways. Maybe it's just me.

    /*best notation*/
    decimal consolidation = GL.Consolidate(item);
    ERP.O2C = consolidation;
    AVCO.PurchasedTotal = consolidation;
    
Page 1 of 1 (43 items)
Powered by Community Server (Non-Commercial Edition), by Telligent Systems