• (cs) in reply to TheMagic8Ball
    TheMagic8Ball:
    #define ALL_SIGNS_POINT_TO_YES 13

    The FILE_NOT_FOUND references are expected, but... this is actually pretty funny.

  • Pon (unregistered) in reply to merreborn's nemesis
    merreborn's nemesis:
    Seriously, using #define to redefine true and false is just stupid. The programmer should just have to return true, false, or (as seems to be needed here) an enum value.

    enum { Intersects, Tangent, Disjoint };

    CAPTCHA: tesla...as in shockingly bad code

    Or, for bounding volumes, Contains instead of Tangent.

  • merreborn's nemesis (unregistered) in reply to Kalinka
    Kalinka:
    Not a WTF.

    When doing geometric intersections you usually first test against a bounding volume (bounding box, bounding sphere) or use some other quick-check.

    The values then correspond to:

    TRUE = shapes definitely intersect MAYBE = bounding volumes definitely intersect, shapes may or may not FALSE = shapes definitely do not intersect

    Can we please have WTFs posted by people who can actually spot them? So far it seems like WTFs are "what some junior-junior-newbie-temp worker doesn't understand and therefore calls a WTF with no attempt at all to understand", or general whining of the type "My stupid boss says 2+2=5, WTF!"

    True WTFs are much more subtle. They are not caused by stupidity, nor by ignorance. They are when perfectly rational people do what is perfectly rational at the time - with no deadlines and stupid bosses - but which turns out to be completely wrong in retrospect.

    I know, because I have at least a dozen of them to my name.

    Using #define to redefine true and false is stupid. Always.

    CAPTCHA: pirates...rar!

  • Bluemoon (unregistered)

    Hmm, I wonder what happens if you compile it with the option -DTRUE=0 ?

    Funny things will happen: TRUE == FALSE TRUE != MAYBE FALSE != MAYBE

  • (cs) in reply to merreborn's nemesis
    merreborn's nemesis:

    Using #define to redefine true and false is stupid. Always.

    CAPTCHA: pirates...rar!

    Then how do you get true and false in C code if you can't use C99? Or are you going to say that using C89 is always stupid?

    (This is half challenging your assertion, but there's also a very large chance that there is a better way that I don't know about. My comfort is in C++ moreso than C, and so I get bools from the language. ;-))

  • nworb (unregistered)

    This is useful sometimes - in problem solving code for instance. What would your answer be if I asked you - am I taller than 6'? Would you have the highest chance of being right if you said True, False, or Maybe?

  • whicker (unregistered)

    What I do is define an enum with the different states that the system can be in. Then document it and hope that somebody else doesn't come along and ! it in the retarded langages that allow that sort of thing.

  • (cs) in reply to Bluemoon
    Bluemoon:
    Hmm, I wonder what happens if you compile it with the option -DTRUE=0 ?

    Funny things will happen: TRUE == FALSE TRUE != MAYBE FALSE != MAYBE

    OTOH, what happens if you compile c++ code with -Dtrue=false?

    If anything, this is a WTF with the C language that you can do this sort of thing, not with this code.

  • Beretta (unregistered) in reply to Bluemoon

    And this is why geometric networks suck.

    I run through the MAYBE situation all the time. Points that should be coincident get seperated due to poor precision or data corruption. So you have to pretty much run a buffer trying to catch all items that are within, oh...say .001 inches of each other. At this point, you'll have to go back and inspect all these MAYBE situations to see if they were supposed to be intersecting or if they truly were supposed to be .001 inches apart. If you assume all .001 inche separations are supposed to be intersecting, you can pretty much destroy a network in an instant.

  • (cs) in reply to EvanED
    EvanED:
    merreborn's nemesis:

    Using #define to redefine true and false is stupid. Always.

    CAPTCHA: pirates...rar!

    Then how do you get true and false in C code if you can't use C99? Or are you going to say that using C89 is always stupid?

    (This is half challenging your assertion, but there's also a very large chance that there is a better way that I don't know about. My comfort is in C++ moreso than C, and so I get bools from the language. ;-))

    Ahem...too young to have used that version of C. Didn't know true and false were ever NOT defined in C. In that case, you might reasonably #define true 1 and #define false 0, but certainly not #define maybe 2...

  • (cs) in reply to merreborn's nemesis
    merreborn's nemesis:
    Kalinka:
    Not a WTF. [...] I know, because I have at least a dozen of them to my name.

    Using #define to redefine true and false is stupid. Always.

    CAPTCHA: pirates...rar!

    Variant on "#define true ..."...

    I once encountered someone who did this:

    #define define 
    

    so that

    #define max(a,b)
    

    became

    # max(a,b)
    

    which confuses the hell out of the preprocessor.

    He stuck it in the middle of a VERY long sequence of "#define's", and checked it in. Naturally, nothing compiled after the next checkout. It took a while to find it.

  • Ben (unregistered) in reply to Peter Antoine
    Peter Antoine:
    Winter:
    mkb:
    Winter:
    Did anyone mention FILE_NOT_FOUND yet because I think about 30 more people should post that. Also can we define BRILLANT as well for completeness

    Don't give them ideas. This board doesn't understand the concept of shelflife when applied to injokes.

    3 things I've noticed and stop me from wanting to register to post here:

    "FIRST POST!!11!" occurring for three quarters of the first page of any public discussion

    "The REAL WTF is ____" followed by some extremely dodgy code (usually)

    and then the template posts. (What no FILE_NOT_FOUND?!, Man that sounds like job for PAULA BEAN! etc etc)

    captcha is stinky. Damn right!

    You forgot:

    1. Reading the problem in the wrong language. (i.e. C as C#)
    2. It should have been written in .... (usually Ruby, Python)
    3. Assuming we are all web/database programmers.
    Your forgot to say what your captcha was, because people definitely care about that.
  • Anonymous (unregistered) in reply to Kalinka
    Kalinka:
    Not a WTF.

    When doing geometric intersections you usually first test against a bounding volume (bounding box, bounding sphere) or use some other quick-check.

    The values then correspond to:

    TRUE = shapes definitely intersect MAYBE = bounding volumes definitely intersect, shapes may or may not FALSE = shapes definitely do not intersect

    Can we please have WTFs posted by people who can actually spot them? So far it seems like WTFs are "what some junior-junior-newbie-temp worker doesn't understand and therefore calls a WTF with no attempt at all to understand", or general whining of the type "My stupid boss says 2+2=5, WTF!"

    True WTFs are much more subtle. They are not caused by stupidity, nor by ignorance. They are when perfectly rational people do what is perfectly rational at the time - with no deadlines and stupid bosses - but which turns out to be completely wrong in retrospect.

    I know, because I have at least a dozen of them to my name.

    Judging by the vitriol in your reply, I'm guessing this was one of them...

  • haertchen (unregistered) in reply to Kalinka
    Kalinka:
    Not a WTF.

    When doing geometric intersections you usually first test against a bounding volume (bounding box, bounding sphere) or use some other quick-check.

    The values then correspond to:

    TRUE = shapes definitely intersect MAYBE = bounding volumes definitely intersect, shapes may or may not FALSE = shapes definitely do not intersect

    Can we please have WTFs posted by people who can actually spot them? So far it seems like WTFs are "what some junior-junior-newbie-temp worker doesn't understand and therefore calls a WTF with no attempt at all to understand", or general whining of the type "My stupid boss says 2+2=5, WTF!"

    True WTFs are much more subtle. They are not caused by stupidity, nor by ignorance. They are when perfectly rational people do what is perfectly rational at the time - with no deadlines and stupid bosses - but which turns out to be completely wrong in retrospect.

    I know, because I have at least a dozen of them to my name.

    You are correct that the need for multiple return values is not trivial. However, the naming system "TRUE", "FALSE", and "MAYBE", is a terrible approach to solving it, for two reasons:

    (1) Side effects. Changing true and false is a bad idea, as others have said. It is much better to work in your own custom-made space if multiple return values are appropriate.

    (2) True and False may be specific enough for what you mean in this case, but Maybe should probably be better defined; e.g. the programmer maintaining the program should have some idea, from the name alone, when it will be returned.

  • (cs) in reply to snoofle
    snoofle:
    merreborn's nemesis:
    Kalinka:
    Not a WTF. [...] I know, because I have at least a dozen of them to my name.

    Using #define to redefine true and false is stupid. Always.

    CAPTCHA: pirates...rar!

    Variant on "#define true ..."...

    I once encountered someone who did this:

    #define define 
    

    so that

    #define max(a,b)
    

    became

    # max(a,b)
    

    which confuses the hell out of the preprocessor.

    He stuck it in the middle of a VERY long sequence of "#define's", and checked it in. Naturally, nothing compiled after the next checkout. It took a while to find it.

    That's a terribly broken compiler I think...

    4. ~: cat > delete.c
    #define define
    #define max(a,b) ((a)>(b)?(a):(b))
    
    max(6,7)
    5. ~: gcc -E delete.c
    # 1 "delete.c"
    # 1 "<built-in>"
    # 1 "<command line>"
    # 1 "delete.c"
    
    
    
    ((6)>(7)?(6):(7))
    
  • (cs) in reply to Winter
    Winter:
    3 things I've noticed and stop me from wanting to register to post here:

    "FIRST POST!!11!" occurring for three quarters of the first page of any public discussion

    "The REAL WTF is ____" followed by some extremely dodgy code (usually)

    and then the template posts. (What no FILE_NOT_FOUND?!, Man that sounds like job for PAULA BEAN! etc etc)

    captcha is stinky. Damn right!

    You forgot:

    People who obsessively post their captcha for no discernable reason.

  • (cs) in reply to EvanED
    EvanED:
    snoofle:
    merreborn's nemesis:
    Kalinka:
    Not a WTF. [...] I know, because I have at least a dozen of them to my name.

    Using #define to redefine true and false is stupid. Always.

    CAPTCHA: pirates...rar!

    Variant on "#define true ..."...

    I once encountered someone who did this:

    #define define 
    

    so that

    #define max(a,b)
    

    became

    # max(a,b)
    

    which confuses the hell out of the preprocessor.

    He stuck it in the middle of a VERY long sequence of "#define's", and checked it in. Naturally, nothing compiled after the next checkout. It took a while to find it.

    That's a terribly broken compiler I think...

    4. ~: cat > delete.c
    #define define
    #define max(a,b) ((a)>(b)?(a):(b))
    
    max(6,7)
    5. ~: gcc -E delete.c
    # 1 "delete.c"
    # 1 "<built-in>"
    # 1 "<command line>"
    # 1 "delete.c"
    
    
    
    ((6)>(7)?(6):(7))
    

    Agreed - this was a very long time ago - pre-gcc - compilers were somewhat less resilient back then

  • pete (unregistered)

    MAYBE XOR MAYBE = FALSE

  • dolo54 (unregistered)

    dammit! I thought there were only three booleans! Now there's a fourth?!? Arrgh. Welcome to the wonderful world of quantum computing. "boolean values: true, false, maybe, both"

  • Luke (unregistered) in reply to snoofle

    Variant on "#define true ..."...

    I once encountered someone who did this:

    #define define

    so that

    #define max(a,b)

    became

    max(a,b)

    which confuses the hell out of the preprocessor.

    ... fires up his editor ..

    // foo.c #define define #define foo 1

    int main() { printf("%d\n", foo); }

    % gcc -o foo foo.c % ./foo 1

    Hmm. What compiler were you using?

  • webdev101 (unregistered) in reply to bobby

    There can be many valid reasons for MAYBE. E.g. Is there life in galaxy outside milkyway? If you say Yes: How can you tell? Did you see it? If you say NO: How can you tell? Did you visit each and every planet in each and every galaxy and verified? If you say NULL (No status): Not true the fact is the value is going to be TRUE or FALSE even if you do not know.

  • (cs)

    #define NOT_UNLIKELY -1

  • (cs) in reply to dolo54
    dolo54:
    dammit! I thought there were only three booleans! Now there's a fourth?!? Arrgh. Welcome to the wonderful world of quantum computing. "boolean values: true, false, maybe, both"
    #DEFINE UP, DOWN, TOP, BOTTOM, STRANGE, CHARMED
  • slashdevslashnull (unregistered)

    It would have been amusing if he'd at least have used 'mu' instead of 'maybe'. Actually, this whole things reminds me of the 'Nullity' fiasco.

    People posting their captchas: hey, it's a great way to help out the spambots. Then they just have to scan for "captcha:" and make a (small) list of the following words. That way they know what words to try.

  • Orion Adrian (unregistered)

    This isn't a WTF at all. There are plenty of libraries that define a non-true, non-false condition. COM has tristate condition defined.

    Additionally enums aren't always the best choice if the coding library you're using already defines TRUE 1, FALSE 0 and UNKNOWN/MAYBE 2. There's a lot of code out there that already uses #defines for true and false in C. The problem is C doesn't have a native bool type. #defining TRUE as 1 and FALSE as 0 is very common. To give an example from the Microsoft Win32 library, windef.h:

    #ifndef FALSE #define FALSE 0 #endif

    #ifndef TRUE #define TRUE 1 #endif

    Don't presume.

  • (cs) in reply to Beretta
    Beretta:
    And this is why geometric networks suck.

    I run through the MAYBE situation all the time. Points that should be coincident get seperated due to poor precision or data corruption. So you have to pretty much run a buffer trying to catch all items that are within, oh...say .001 inches of each other. At this point, you'll have to go back and inspect all these MAYBE situations to see if they were supposed to be intersecting or if they truly were supposed to be .001 inches apart. If you assume all .001 inche separations are supposed to be intersecting, you can pretty much destroy a network in an instant.

    1.) That's the way you have to work with floating point number representations anyway: define your tolerances or get them from the subject matter experts and then use them - always.

    2.) WTF: somebody is STILL using inches for this kind of stuff.

  • Winter (unregistered) in reply to Zylon
    Zylon:
    You forgot:

    People who obsessively post their captcha for no discernable reason.

    I post it when it's funny or relevant, there's nothing wrong with that. 1 line of text isn't going to make or break a post. People who post it for no reason at all should be given a mild electric shock

  • zack (unregistered)

    where's the magic 8 ball constants?

    #define OUTLOOK_NOT_SO_GOOD = 5 #define MY_SOURCES_SAY_NO = 6 #define CANNOT_PREDICT_NOW = 7 #define DONT_COUNT_ON_IT = 8

  • Nem (unregistered)

    Funny, I always used:

    #define MAYBE (rand() % 2)

    Keeps things interesting... j/k.

  • (cs) in reply to Luke
    Luke:
    > Variant on "#define true ..."... > > I once encountered someone who did this: > > #define define > > so that > > #define max(a,b) > > became > > # max(a,b) > > which confuses the hell out of the preprocessor.

    ... fires up his editor ..

    // foo.c #define define #define foo 1

    int main() { printf("%d\n", foo); }

    % gcc -o foo foo.c % ./foo 1

    Hmm. What compiler were you using?

    As I recall, this was late 70's/early 80's-ish, and we were working with some crappy VAX/VMS system on a military contract. For some reason, without something that it recognized after the "#", the pre-processor ignored the intervening spaces, and took the directive as "#<whatever came after the original 'define'>", didn't recognize it, and puked.

    Per your, and other examples, the "define" in "#define" seems to be effectively ignored (implied?) in current compilers.

  • (cs) in reply to Ed Heil
    Ed Heil:
    Dude should be programming Haskell!

    It should be pointed out to people that don't know Haskell: in that language, Maybe means "Optional" not "CouldBe". The definition is

    Maybe a = Nothing | Just a

    which translates (roughly) to "Maybe is Nothing or Something".

  • Andreas (unregistered)

    There's not necessarily a WTF here -- there is a host of entirely respectable applications for modal logic, with an obvious extension of two-valued boolean logic.

    True AND Maybe = Maybe True OR Maybe = True NOT Maybe = Maybe

  • (cs) in reply to Kalinka
    Kalinka:
    True WTFs are much more subtle. They are not caused by stupidity, nor by ignorance. They are when perfectly rational people do what is perfectly rational at the time - with no deadlines and stupid bosses - but which turns out to be completely wrong in retrospect.

    I know, because I have at least a dozen of them to my name.

    So submit them already!

  • BAReFOOt (unregistered)

    Did anyone ever think of...

    x = MAYBE | TRUE; // maybe true
    y = MAYBE | FALSE; // maybe false
    

    Remembers me of haskell's...

    theGovernmentIsEvil :: Maybe
    theGovernmentIsEvil = Just True
    

    ...and then in the interactive shell...

    Main> theGovernmentIsEvil
    Just True :: Maybe Bool
    
  • Ben (unregistered) in reply to Winter
    Winter:
    Zylon:
    You forgot:

    People who obsessively post their captcha for no discernable reason.

    I post it when it's funny or relevant, there's nothing wrong with that. 1 line of text isn't going to make or break a post. People who post it for no reason at all should be given a mild electric shock

    Yeah, they're always about as relevant as this: captcha: pirates. Pirates would make the guy who wrote this walk the plank! captcha: kungfu. This guy who wrote this WTF obviously has weak kung fu. captcha: tacos. mmmm... now I'm hungry! captcha: doom. Just like this program is doomed!

    which just happened to be the first 4 captchas I was shown with each refresh. Dear god, quit it, it makes you look like an idiot who both has no sense of humor and has also never seen the internet before today.

  • paste (unregistered) in reply to Moose
    Moose:
    I don't see this as a WTF. There are many uses for multi-value logic such as an elevator system.

    Yes. Last time I was in an elevator, I wanted to get to the false^th floor, but the guy infront had already pushed for the maybe^th.

    Captcha: Hit preview for same captcha but with different colors?

  • (cs) in reply to nworb
    nworb:
    This is useful sometimes - in problem solving code for instance. What would your answer be if I asked you - am I taller than 6'? Would you have the highest chance of being right if you said True, False, or Maybe?

    You would write that as:

    if (yourheight == NULL) ThenYouBetterGoFindOutWhatItIs();

    if (yourheight > 6) DoSomething(); elseif (yourheight <= 6) DoSomethingElse()

    There is no "maybe" unless yourheight is undefined. In which case your program has an error. The case of "maybe" means you don't have enough information to complete the program.

  • ElQuberto (unregistered)

    Trinary fuzzy logic. I'm missing the WTF, this is more like genius thesis material.

  • (cs) in reply to Edowyth
    merreborn's nemesis:
    Using #define to redefine true and false is stupid. Always.

    Indeed, though "redefine" should be "define". And C99's stdbool.h is also largely stupid, though at least it standardized this particular bit of stupidity.

    Defining FALSE in C, however popular it may be, is a pointless crutch. Any competent C programmer knows that in C, 0 is false. End of story.

    Defining TRUE in C is even worse, because it leads to errors such as "if (expression == TRUE)" where expression has a value that's neither 0 nor whatever TRUE is defined to be. (It should be 1, because that's the result of a comparison operator in a non-false expression, but I've seen plenty of code that doesn't even get that right.) Since C has multiple "true" values, defining one as the value of "true" leads to code that doesn't do what it appears to do.

    EvanED:
    Then how do you get true and false in C code if you can't use C99? Or are you going to say that using C89 is always stupid?

    In C, false is 0, or anything that evaluates to 0 in a conditional context, such as a null pointer. True is anything that's not false.

    Anyone who doesn't understand that isn't qualified to write C code for real use. Nothing wrong with that; I dabble in plenty of languages (APL, OCaml, Unlambda,...) I'm not qualified to use in anger. Unfortunately, there's a great deal of extant C code written by the unqualified.

    Edowyth:
    Ahem...too young to have used that version of C.

    Really? That (or, more likely, ISO 9899-1990 plus the rarely-used 1994 extensions) is what nearly all C programmers use. Of course, there are also many people who use "GNU C", which is a language similar to but not quite C.

    Almost no one actually uses C99 (ISO 9899-1999), because there are very few conforming implementations.

    Edowyth:
    Didn't know true and false were ever NOT defined in C. In that case, you might reasonably #define true 1 and #define false 0, but certainly not #define maybe 2...

    No, you might not "reasonably" do that. That would still be stupid.

    -- Michael Wojcik

  • Kurt Werle (unregistered) in reply to Moose
    Moose:
    I don't see this as a WTF. There are many uses for multi-value logic such as an elevator system.

    --- Sampe.h ---

    #ifndef TRUE #define TRUE 0xFF #endif

    #include "WTF_Example.h"

    ---- Sample2.h --- #include Sample.h #include WTF_Example.h

    --- Sample3.h --- #include WTF_Example.h #include Sample.h

    --- Sample3.c --- ... if (someValue != TRUE) // WTF? I know this value isn't true here, why isn't my condition executing!? ...

    --- Better.h ---

    #ifndef BETTER_TRINARY_TRUE #define BETTER_TRINARY_TRUE 1 #endif

    #ifndef BETTER_TRINARY_FALSE #define BETTER_TRINARY_FALSE 0 #endif

    #ifndef BETTER_TRINARY_MAYBE #define BETTER_TRINARY_MAYBE 2 #endif

    etc.

  • smetzger (unregistered) in reply to merreborn's nemesis
    merreborn's nemesis:

    Using #define to redefine true and false is stupid. Always.

    CAPTCHA: pirates...rar!

    true and false are not defined in all languages. They are not defined in C. C++ also didn't have a true bool type for a long time.

    This isn't a WTF, a little sloppy for not using an enum. But not a WTF.

    And as for not checking if MAYBE is previously defined. Compiler should catch that one.

  • (cs) in reply to Orion Adrian
    Orion Adrian:
    This isn't a WTF at all. There are plenty of libraries that define a non-true, non-false condition. COM has tristate condition defined.

    Additionally enums aren't always the best choice if the coding library you're using already defines TRUE 1, FALSE 0 and UNKNOWN/MAYBE 2. There's a lot of code out there that already uses #defines for true and false in C. The problem is C doesn't have a native bool type. #defining TRUE as 1 and FALSE as 0 is very common. To give an example from the Microsoft Win32 library, windef.h:

    #ifndef FALSE #define FALSE 0 #endif

    #ifndef TRUE #define TRUE 1 #endif

    Don't presume.

    Presume? What should we not presume...to question the dubious practice of using compiler directives to define constant return values?...to question the dubious practice of using compiler directives to define TRUE and FALSE?...or to question MICROSOFT???

    I think, sir, you presume too much!

    Also on the following quote:

    paste:
    Moose:
    I don't see this as a WTF. There are many uses for multi-value logic such as an elevator system.

    Yes. Last time I was in an elevator, I wanted to get to the false^th floor, but the guy infront had already pushed for the maybe^th.

    You know I had the exact same problem in my elevator the other day! Maybe if the 'multi-value logic' user used 'multi-value data structures' they wouldn't have ended up here...now if only we could find such a structure...

    enum { value1, value2, value3 } StupidExample;

    hmmm, I wish C provided such a thing...

    enum { apple, banana, camero } CarFruit;

    ...maybe I'll write them with a feature request...

    enum { Intersects, Tangent, NotToucing } Geometry;

    whatever shall we do to help us with our 'multi-value logic'???

  • (cs) in reply to Jno
    Jno:
    Fer crissakes, it's a missile. Count the letters, and pronounce as two syllables. Miss'eyell. There. Also please refrain from throwing them at friendly military convoys. Thank you.

    Sorry about that, my spell checker said 'missle' was MAYBE correct, so I just went with it...

  • Scotty (unregistered) in reply to mkb

    Perhaps you could clarify why this is bad: enum { FOO = 2, BAR, BAZ}

    I used to program in Ada, and it was very convenient to use an enumeration for its strong type checking. As the language was originally designed for military applications, like real-time flight control systems, being able to specify the starting value, or all values, used to represent the enumation constants allowed for making the software compatible with the underlying hardware, which would be using those values in some registers.

  • Blah (unregistered)

    Yeah, this is a true WTF. The system I work on has:

    #define MAYBE -1

    ...which is obviously far superior.

  • (cs) in reply to Unomi
    Unomi:
    Indeed it is somewhat philosophic or forward-compatible with quantum informatica like someone else mentioned.

    While it can not be defined as TRUE, it is simply FALSE. Who doesn't try to shoot, will always miss. So negative is default here. You can't say, 'Who doesn't try to shoot, will maybe miss'. Simple not true (thus false).

    MAYBE is like 'IT_DEPENDS' or coming to some inner_check_function_wisdom to be called and resulting in either TRUE, FALSE or BOTH. Japanese people could refer to a status called 'MU'..... Not typical programming (thus an anti-pattern).

    CAPTCHA: ewww (indeed, to ugly to even spit on)

    • Unomi -

    Actually, if you define "miss" as "an attempt made which was not successful", then those who don't shoot never miss. They never hit either.

    Thus, you have predicate conditions which have a causal determination of the validity of your statement.

    It's better to say that there are conditions which, if not false, are definitely true. If you shoot, you either hit or miss, but if you don't shoot, you neither hit nor miss, that's a 3-value calculation (1: did not shoot; 2: shot and missed; 3: shot and hit).

    "Did not shoot" could very well be a "if you'd shot, maybe you would have hit, or maybe not". Thus the validity of the 3-value test.

    Since programs are meant to operate in a real universe, not a mathematical universe, in most cases, true/false/maybe becomes a valid measure. Could also be reworded as "true"/"false"/"unverified result".

    That has real-world applications. Thus, it can have a valid place in software which is meant to have some bearing on the real world.

  • (cs) in reply to Scotty
    Scotty:
    Perhaps you could clarify why this is bad: enum { FOO = 2, BAR, BAZ}

    I used to program in Ada, and it was very convenient to use an enumeration for its strong type checking. As the language was originally designed for military applications, like real-time flight control systems, being able to specify the starting value, or all values, used to represent the enumation constants allowed for making the software compatible with the underlying hardware, which would be using those values in some registers.

    It's dangerous because it tempts a programmer to behave like an enum is an int, which is NOT the case. There are things you can do to ints that you can't do to enums.

    It is probably not bad in every case (nothing is, really) but people shouldn't assume that an enum is an int with range checking.

  • (cs) in reply to MichaelWojcik
    MichaelWojcik:
    EvanED:
    Then how do you get true and false in C code if you can't use C99? Or are you going to say that using C89 is always stupid?

    In C, false is 0, or anything that evaluates to 0 in a conditional context, such as a null pointer. True is anything that's not false.

    Anyone who doesn't understand that isn't qualified to write C code for real use. Nothing wrong with that; I dabble in plenty of languages (APL, OCaml, Unlambda,...) I'm not qualified to use in anger. Unfortunately, there's a great deal of extant C code written by the unqualified.

    So you suggest writing 0 everywhere and not having symbolic names?

    I don't have a problem with that (I use 0 instead of NULL most of the time), but some people would prefer the names.

  • (cs) in reply to mkb
    mkb:
    Scotty:
    Perhaps you could clarify why this is bad: enum { FOO = 2, BAR, BAZ}

    I used to program in Ada, and it was very convenient to use an enumeration for its strong type checking. As the language was originally designed for military applications, like real-time flight control systems, being able to specify the starting value, or all values, used to represent the enumation constants allowed for making the software compatible with the underlying hardware, which would be using those values in some registers.

    It's dangerous because it tempts a programmer to behave like an enum is an int, which is NOT the case. There are things you can do to ints that you can't do to enums.

    It is probably not bad in every case (nothing is, really) but people shouldn't assume that an enum is an int with range checking.

    Just out of curiosity, a program I worked on a little used the following pattern in a few places. Thoughts?

    enum FlagSet { FLAG_A = 1, FLAG_B = 2, FLAG_C = 4, FLAG_D = 8, FLAG_E = 16 };

    foo( FLAG_A | FLAG_B | FLAG_D );

    It smells a little to me, but it seems to work pretty well, and has advantages over just defining named constants (this is C++ BTW) and using ints or typedefs of ints.

  • Orion Adrian (unregistered) in reply to Edowyth
    Edowyth:
    Orion Adrian:
    This isn't a WTF at all. There are plenty of libraries that define a non-true, non-false condition. COM has tristate condition defined.

    Additionally enums aren't always the best choice if the coding library you're using already defines TRUE 1, FALSE 0 and UNKNOWN/MAYBE 2. There's a lot of code out there that already uses #defines for true and false in C. The problem is C doesn't have a native bool type. #defining TRUE as 1 and FALSE as 0 is very common. To give an example from the Microsoft Win32 library, windef.h:

    #ifndef FALSE #define FALSE 0 #endif

    #ifndef TRUE #define TRUE 1 #endif

    Don't presume.

    Presume? What should we not presume...to question the dubious practice of using compiler directives to define constant return values?...to question the dubious practice of using compiler directives to define TRUE and FALSE?...or to question MICROSOFT???

    I think, sir, you presume too much!

    Also on the following quote:

    paste:
    Moose:
    I don't see this as a WTF. There are many uses for multi-value logic such as an elevator system.

    Yes. Last time I was in an elevator, I wanted to get to the false^th floor, but the guy infront had already pushed for the maybe^th.

    You know I had the exact same problem in my elevator the other day! Maybe if the 'multi-value logic' user used 'multi-value data structures' they wouldn't have ended up here...now if only we could find such a structure...

    enum { value1, value2, value3 } StupidExample;

    hmmm, I wish C provided such a thing...

    enum { apple, banana, camero } CarFruit;

    ...maybe I'll write them with a feature request...

    enum { Intersects, Tangent, NotToucing } Geometry;

    whatever shall we do to help us with our 'multi-value logic'???

    I'm not saying that there isn't a better solution. My point was to say that many rules are bent and broken for compability sake. When I read this I see someone as importing another library that has these defined already (not MAYBE, but TRUE AND FALSE). My guess is the library in question is windef.h or something that itself uses windef.h.

    So the question is, did they screw up because they didn't know they shouldn't do it? Or were they simply not trying to, excuse the pun, redefine TRUE and FALSE but rather use what was already there.

    A lot of things that look like WTFs aren't. They are instead people trying to simplify their lives by working within the libraries and technical realities of the systems and libraries they were given.

    That's what I mean by "Don't presume."

Leave a comment on “Rarely Just TRUE or FALSE”

Log In or post as a guest

Replying to comment #:

« Return to Article