Better just check...



  • [code]
    bool tmp = Settings.Foo;

    if (tmp == !tmp) Debug.Assert(true);

    [/code]

    Always code defensively, even against the basic rules of logic changing...



  • Did they also redefine true so it could actually fail as an assertion?



  • @Julia said:

    <font face="Lucida Console" size="2">
    bool tmp = Settings.Foo;

    if (tmp == !tmp) Debug.Assert(true);

    </font>

    If that doesn't elicit an out loud WTF, what on earth would?



  • Well, let me spell it out for you. Axioms:

    true = !false

    FILE_NOT_FOUND != true

    FILE_NOT_FOUND != false

    Hence

    FILE_NOT_FOUND == !FILE_NOT_FOUND



  • @ekolis said:

    Did they also redefine true so it could actually fail as an assertion?
    obviously if tmp == !tmp evaluates to true, logic has flipped and assert(false) would be assert(true)!



  • @esoterik said:

    @ekolis said:

    Did they also redefine true so it could actually fail as an assertion?
    obviously if tmp == !tmp evaluates to true, logic has flipped and assert(false) would be assert(true)!

    Catch up with trends! true is the new false.



  • This is clearly to protect against concurrency issues. The value of tmp could change between assigment and comparison. It's concurrency 101!



  • @pure said:

    This is clearly to protect against concurrency issues. The value of tmp could change between assigment and comparison. It's concurrency 101!

     

    Yep, this is the way I always do my concurrency checking.  

     



  • @DescentJS said:

    @pure said:

    This is clearly to protect against concurrency issues. The value of tmp could change between assigment and comparison. It's concurrency 101!

     

    Yep, this is the way I always do my concurrency checking.  

     

     

    Some people, when confronted with
    a problem think, “I know, I’ll use threads”, and then two they hav
    erpoblesms.

     


  • Discourse touched me in a no-no place

    @pure said:

    @DescentJS said:
    @pure said:
    This is clearly to protect against concurrency issues. The value of tmp could change between assigment and comparison. It's concurrency 101!

    Yep, this is the way I always do my concurrency checking.

    Some people, when confronted with a problem think, “I know, I’ll use threads”, and then two they hav erpoblesms.
    Perhaps a regex would help?



  • @PJH said:

    @pure said:
    @DescentJS said:
    @pure said:
    This is clearly to protect against concurrency issues. The value of tmp could change between assigment and comparison. It's concurrency 101!

    Yep, this is the way I always do my concurrency checking.

    Some people, when confronted with a problem think, “I know, I’ll use threads”, and then two they hav erpoblesms.
    Perhaps a regex would help?

    I think you could probably subdue the threads with enough XML.


  • Discourse touched me in a no-no place

    @boomzilla said:

    @PJH said:
    @pure said:
    @DescentJS said:
    @pure said:
    This is clearly to protect against concurrency issues. The value of tmp could change between assigment and comparison. It's concurrency 101!
    Yep, this is the way I always do my concurrency checking.
    Some people, when confronted with a problem think, “I know, I’ll use threads”, and then two they hav erpoblesms.
    Perhaps a regex would help?
    I think you could probably subdue the threads with enough XML.
    With, or without RPC?



    (This reminds me - I have a (serious) question about something along these lines - I shall endeavour to find a - most suitable - board to post it on and expect few (useful) replies. Like my last serious question, which did in fact get me an answer....)



  • @PJH said:

    Perhaps a regex would help?
     

    Got 99 prob— ah. 100.



  • @PJH said:

    (This reminds me - I have a (serious) question about something along these lines - I shall endeavour to find a - most suitable - board to post it on and expect few (useful) replies. Like my last serious question, which did in fact get me an answer....)
     

    That's a nasty speech impediment you got there.



  • @pure said:

    Some people, when confronted with
    a problem think, “I know, I’ll use threads”, and then two they hav
    erpoblesms.
     

    This makes it all worthwhile.



  • @dhromed said:

    @PJH said:
    (This reminds me - I have a (serious) question about something along these lines - I shall endeavour to find a - most suitable - board to post it on and expect few (useful) replies. Like my last serious question, which did in fact get me an answer....)
    That's a nasty speech impediment you got there.

    Some people, when confronted with a problem think, "I know, I'll put parentheses inside parentheses." Those people are awful. Kick sand in their face at every opportunity.



  •  I have encountered (x == !x) being True for objects in a published API, from a large software company in Redmond.

     Bad code in an equality operator implementation.



  • @bgodot said:

     I have encountered (x == !x) being True for objects in a published API, from a large software company in Redmond.

    Concur or Nintendo?



  •  $ perl -E '$x = "nonempty string that does not start with a digit"; say $x == !$x;'
    1

    Not really a WTF when you know what == in Perl means (it compares the two arguments when interpreted as numbers, unlike eq which interprets them as stings). The nonempty string that doesn't start with a digit has a numeric value of 0, but is true as a boolean; so if it's negated, it becomes false, which is also 0 when interpreted as a number.

    And Perl recognises that this is a ridiculous misuse of ==; if I'd turned on warnings:

    $ perl -w -E '$x = "nonempty string that does not start with a digit"; say $x == !$x;'
    Argument "nonempty string that does not start with a digit" isn't numeric in numeric eq (==) at -e line 1.
    1



  • @ais523 said:

    And Perl recognises that this is a ridiculous misuse of ==; if I'd turned on warnings:

    $ perl -w -E '$x = "0 but true"; say $x == !$x;'
    1
    

    "0 but true" is, however, not a misuse but an abuse and as such does not get detected ;-).



  • @pure said:

    This is clearly to protect against concurrency issues. The value of tmp could change between assigment and comparison. It's concurrency 101!


    +1.
    (wouldn't that be Concurency 102 than?)



  • @pure said:

    This is clearly to protect against concurrency issues. The value of tmp could change between assigment and comparison. It's concurrency 101!


    Don't be silly. A proper conconcurrency check has to be done twice. Sometimes three times, if you need to be really sure.



  • But now you have a catch-22... to do a proper concurrency check, you need to do it three times in parallel. And of course, some other thread might just come along and wreck your answer anyway.



  • @@Deprecated said:

    But now you have a catch-22... to do a proper concurrency check, you need to do it three times in parallel. And of course, some other thread might just come along and wreck your answer anyway.

    Threads are for bullies. Team players use fibers.



  • @ais523 said:

     $ perl -E '$x = "nonempty string that does not start with a digit"; say $x == !$x;'
    1


    The really impressive thing about the OP is that it's clearly in a language which has some sort of static typing. (In fact, it looks like C#).


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.