• (cs) in reply to Someone Who Couldn't be Bothered to Log On from Work
    Someone Who Couldn't be Bothered to Log On from Work:
    dumbass

    Sorry, I refuse to continue any discussion after an ad hominem attack.

  • Haywood (unregistered)

    I see your Boolean Truths, and I raise you a ParamValueIsTrueAsBoolean.

    protected bool ParamValueIsTrueAsBoolean(string stringvalue) { return (stringvalue.Equals("J") || stringvalue.Equals("Y") || stringvalue.Equals("1") || stringvalue.Equals("j") || stringvalue.Equals("y") || stringvalue.Equals("True") || stringvalue.Equals("true")); }

  • PRMan (unregistered) in reply to Bobbo
    Bobbo:
    I once worked with an in-house language which didn't have the ability to represent decimal points. So all such numbers were multiplied up by 100 or 10000 to retain the .00 or .0000 precision, then passed around/stored as needed, then divided back down for display.

    Genius.

    Microsoft does this for the Office 2007+ data formats because it's faster to do all the conversions, so it can't be all bad.

  • Design Pattern (unregistered) in reply to Someone Who Couldn't be Bothered to Log On from Work
    Someone Who Couldn't be Bothered to Log On from Work:
    The only point that stands is the one on the top of your head, dumbass. You obviously have no clue how compilers work
    It is you who obviously has no idea how computers work!
    Someone Who Couldn't be Bothered to Log On from Work:
    1. It is impossible to store a boolean in anything less than a byte because COMPUTERS are incapable of addressing a smaller portion of memory than that. Point destroyed.
    Like already stated by other users it is obviously possible to group up to 8 booleans into one byte and modern programming languages provide auxiliary classes to support that. But even in C it was very usual practice to use bit masks to store multiple booleans into one byte or int.
    Someone Who Couldn't be Bothered to Log On from Work:
    2. Why would boolean comparisons take any longer than character comparisons? Either one is an AND instruction at the machine level and a check if a register is set afterwards. Point destroyed.
    In a programming language where a character is defined to be 16Bit wide, a comparison can indeed run longer when the code is compiled for an 8Bit-processor.

    Those are still in wide use on embedded systems (without filesystems).

    Someone Who Couldn't be Bothered to Log On from Work:
    3. I am not talking about strings, I am talking about CHARACTERS. In case you haven't noticed, there's a difference between the two in all languages. Having a) the flexibility to introduce new values, and b) the specificity of using "Y/N" vs. "T/F" vs. "1/0" vs. "M/F" when appropriate is an enormous advantage.
    What's the "advantage" of todays WTF having a value that represents both false and "not-false"?
    Someone Who Couldn't be Bothered to Log On from Work:
    How could you manage to get all three points wrong?
    Now, how could you manage to get all three points wrong?
  • Guillaume (unregistered) in reply to Fizzle
    Fizzle :
    What's a SOC4?
    Protection exception.

    Don't ask how I know.

  • ÃÆâ€â„ (unregistered)

    The only place you would typically see this is in an academic setting. I still have professors insist I learn FORTRAN.

  • Valczir (unregistered) in reply to Correcterer
    Correcterer:
    Jeff:
    Gotta correct everyone.

    CICS and VSAM DOESN'T run on the AS/400 (iSeries, System i5, System i, whatever IBM is calling it these days.)

    It has it's own operating system and database. So if he was running into CICS and VSAM, it's a Z/OS mainframe.

    And the AS/400 when it was first released was called a mini-computer. Don't ask why the distinction.

    Bob would like to have a word with you.

    Best image ever. Bookmarked.

    Really, when people speaking English as a second language can get this one and Americans can't, you know something has gone horribly wrong.

    On topic: 'N' == True and 'N' == False ... I have no friggin' clue how I'd handle that monstrosity. Probably just try to refactor in a bit of sanity.

    git checkout dev; while code fails; do refactor and fix boolean values; make; done; git checkout master; git merge dev; git commit -a -m "Fixed retarded-ass boolean crap to make some semblance of sense"; git push; get fired for wasting your time on something that works already; feel content in the knowledge that you prevented your replacement from committing suicide;

  • (cs) in reply to hoodaticus
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:

    In C, there is no boolean data type. That's why everyone uses int.

    Please try again. You are only wrong by 11 years. Granted, Windows and *nix, being over 11 years old, don't use it, but it still exists.

  • Fennec (unregistered) in reply to Pyrexkidd
    Pyrexkidd:
    In perl there are no boolean data types. You can however, TEST for boolean values. All values other than "" or "0" are true (strings, int, float, etc (although perl doesn't have these data types either)). Conversely the only false values are "" or "0".

    'undef' would like to have a word with you. (To say nothing of empty arrays/hashes.)

  • OldJavaGuy (unregistered) in reply to WhiskeyJack

    I like PIC 9(5)V99.

  • m (unregistered) in reply to hoodaticus
    hoodaticus:
    In C, there is no boolean data type. That's why everyone uses int.

    TRWTF is still using C89 in 2010… (Ok, C99’s _Bool is no great improvement—it’s basically just an other unsigned int. Looks like TAWTF is C)

  • trwtf (unregistered) in reply to slavik262
    slavik262:
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:

    In C, there is no boolean data type. That's why everyone uses int.

    Please try again. You are only wrong by 11 years. Granted, Windows and *nix, being over 11 years old, don't use it, but it still exists.

    Sorry, slavik, but he's still right. To quote from your preferred source:

    Wikipedia:
    The macros as defined in IEEE Std 1003.1-2001 are :
    * bool which expands to _Bool
    * true which expands to 1
    * false which expands to 0
    

    So they're still using ints, they're just calling them bools.

    The code sample included makes it pretty clear, for those who aren't familiar with C:

    Wikipedia:
      while (keep_going) {
        printf("This will run as long as want to keep going.\n");
        keep_going = false;    // Could also be `keep_going = 0;`
      }
    

    (note the comment)

  • m (unregistered) in reply to Someone Who Couldn't be Bothered to Log On from Work
    Someone Who Couldn't be Bothered to Log On from Work:
    2. Why would boolean comparisons take any longer [sic!] than character comparisons? Either one is an AND instruction at the machine level and a check if a register is set afterwards.
    your point is almost valid for:
    if (flag == '\0') …
    i don’t see where the AND is, here, though
  • someone (unregistered) in reply to trwtf
    trwtf:
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    jpers' comment made me wonder if I could come up with a way to store booleans in less than a byte without making a really wtf-rific mess of it. The only thing I can think of would be to collect all of the booleans in a given program and store them in a "boolean pool" which would be as many bytes as needed, which would allow you to address them by grabbing that byte (or two bytes, or whatever your machine grabs) and looking for the correct bit. So your first boolean would require as much space as before, but your next seven would fit in the same byte as the first. Sounds like a bit of a nuisance to me. Sorry, no, a lot of a nuisance.

    But of course we're all aware that booleans aren't used to save space, they're used to constrain the possible values a boolean variable can take. That is, they exist to clarify the code, not to minimize the memory used.

    struct bit fields in c: http://www.cs.cf.ac.uk/Dave/C/node13.html#SECTION001320000000000000000

  • kraken66j (unregistered) in reply to hoodaticus
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    Dude, seriously Shut the F up if you don't know what you're talking about. You're as dumb as they get.

  • kraken66j (unregistered) in reply to trwtf
    trwtf:
    slavik262:
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:

    In C, there is no boolean data type. That's why everyone uses int.

    Please try again. You are only wrong by 11 years. Granted, Windows and *nix, being over 11 years old, don't use it, but it still exists.

    Sorry, slavik, but he's still right. To quote from your preferred source:

    Wikipedia:
    The macros as defined in IEEE Std 1003.1-2001 are :
    * bool which expands to _Bool
    * true which expands to 1
    * false which expands to 0
    

    So they're still using ints, they're just calling them bools.

    The code sample included makes it pretty clear, for those who aren't familiar with C:

    Wikipedia:
      while (keep_going) {
        printf("This will run as long as want to keep going.\n");
        keep_going = false;    // Could also be `keep_going = 0;`
      }
    

    (note the comment)

    trwtf you are 100% correct about the _Bool, but by asserting there are not bool types and people only use integers, the moron is stating erroneous concepts.

  • (cs) in reply to Pyrexkidd
    Pyrexkidd:
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    In perl there are no boolean data types. You can however, TEST for boolean values. All values other than "" or "0" are true (strings, int, float, etc (although perl doesn't have these data types either)).
    Conversely the only false values are "" or "0".

    so in perl "N", "Y", "FnF", "1", "ReallyFalse", "ExtraFalse", "Maybe" all test true.

    Any way, that's my $.02.

    You forgot undef.

  • clownzor (unregistered) in reply to jpers36

    Ad hominem != insult. If he had said "Your argument is wrong because you are a dumbass", that would be an ad hominem. However, he clearly listed the reasons he thought you were wrong. That is not an ad hominem, idiot.

  • Ouch! (unregistered) in reply to clownzor
    clownzor:
    Ad hominem != insult. If he had said "Your argument is wrong because you are a dumbass", that would be an ad hominem. However, he clearly listed the reasons he thought you were wrong. That is not an ad hominem, idiot.
    He wrote "ad hominem attack", which calling someone a dumbass clearly is. He didn't accuse whomever of a logical fallacy but of bad behaviour.
  • nobody (unregistered) in reply to jugis
    jugis:
    Bruce:
    null:
    CICS is the same age as Unix.
    Yes, but wine improves with age, and milk doesn't.
    Wine turns to vinegar.
    Nope. Age does not convert wine to vinegar. Exposure to oxygen does. Have you never considered the fact that the best wines are aged by many years?
  • nobody (unregistered) in reply to Someone Who Couldn't be Bothered to Log On from Work
    Someone Who Couldn't be Bothered to Log On from Work:
    jpers36:
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    I googled for an example of a language which uses a bit boolean, and c came up in an IBM MAC OS X c/c++ compiler guide. So I may be wrong in my specific example, or I may be right but only for a highly specific flavor of c. I haven't actually touched c since college, so please forgive me for this.

    The points still stand.

    The only point that stands is the one on the top of your head, dumbass. You obviously have no clue how compilers work (which is probably why you had to google to see what c was).

    1. It is impossible to store a boolean in anything less than a byte because COMPUTERS are incapable of addressing a smaller portion of memory than that. Point destroyed.
    Bitmask, douchewaffle. Google it.
    2. Why would boolean comparisons take any longer than character comparisons? Either one is an AND instruction at the machine level and a check if a register is set afterwards. Point destroyed.
    Because you have to load the byte (which contains your bit and 7 other bit variables) and then mask out your bit and then compare it. Google it.
    3. I am not talking about strings, I am talking about CHARACTERS. In case you haven't noticed, there's a difference between the two in all languages. Having a) the flexibility to introduce new values, and b) the specificity of using "Y/N" vs. "T/F" vs. "1/0" vs. "M/F" when appropriate is an enormous advantage.
    And you end up with the indeterminism of 'N' and 'F' both representing both True and False. Which is what today's story was all about, in case you missed it.
    How could you manage to get all three points wrong? I'm guessing it's you who's the troll.
    Pot, meet Kettle.
  • (cs) in reply to kraken66j
    kraken66j:
    trwtf:

    So they're still using ints, they're just calling them bools.

    The code sample included makes it pretty clear, for those who aren't familiar with C:

    Wikipedia:
      while (keep_going) {
        printf("This will run as long as want to keep going.\n");
        keep_going = false;    // Could also be `keep_going = 0;`
      }
    

    (note the comment)

    trwtf you are 100% correct about the _Bool, but by asserting there are not bool types and people only use integers, the moron is stating erroneous concepts.

    Not quite, if int means int. The standard says _Bool is an unsigned integer type large enough to hold the values 0 and 1. It could be an unsigned integer type with one value bit and seven padding bits, thus only capable of holding two values, like a real boolean. gcc almost treats it as such, the only way to get a value other than 0 or 1 into a _Bool I'm aware of is direct memory access (memcpy or pointer casting), but if you have done that and cast the _Bool to an unsigned char (or int, what have you), you get a value-preserving extension and not only the 0 and 1 values you'd get for an unsigned integer type with one value bit. Anyway, my gcc says sizeof(_Bool) = 1, so they're not using ints for _Bool. If int stands for "some integer type", then yes, 100%.

  • (cs) in reply to nobody
    nobody:
    Someone Who Couldn't be Bothered to Log On from Work:
    jpers36:
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    I googled for an example of a language which uses a bit boolean, and c came up in an IBM MAC OS X c/c++ compiler guide. So I may be wrong in my specific example, or I may be right but only for a highly specific flavor of c. I haven't actually touched c since college, so please forgive me for this.

    The points still stand.

    The only point that stands is the one on the top of your head, dumbass. You obviously have no clue how compilers work (which is probably why you had to google to see what c was).

    1. It is impossible to store a boolean in anything less than a byte because COMPUTERS are incapable of addressing a smaller portion of memory than that. Point destroyed.
    Bitmask, douchewaffle. Google it.
    2. Why would boolean comparisons take any longer than character comparisons? Either one is an AND instruction at the machine level and a check if a register is set afterwards. Point destroyed.
    Because you have to load the byte (which contains your bit and 7 other bit variables) and then mask out your bit and then compare it. Google it.
    Mostly, masking your bit is not required. You either AND it with whatever your true(or false) representation is. Of course, if you are using bitmasks, you have the extra step of masking it, making using bit booleans slower. Remember, you cannot load less than a byte on a processor. indeed, you cannot load less than 4 bytes!
    3. I am not talking about strings, I am talking about CHARACTERS. In case you haven't noticed, there's a difference between the two in all languages. Having a) the flexibility to introduce new values, and b) the specificity of using "Y/N" vs. "T/F" vs. "1/0" vs. "M/F" when appropriate is an enormous advantage.
    And you end up with the indeterminism of 'N' and 'F' both representing both True and False. Which is what today's story was all about, in case you missed it.
    How could you manage to get all three points wrong? I'm guessing it's you who's the troll.
    Pot, meet Kettle.
  • Patrick (unregistered)

    From an ini file parser:

    ToBool(string s){
     switch(s.ToLower()){
      case "":
      case "0":
      case "n":
      case "no":
      case "off":
      case "false":
       return false;
     }
     return true;
    }
  • Gavin (unregistered) in reply to Anonymous
    Anonymous:
    --> "F" - represents False --> "N" - represents Not False --> "FNF" - represents File Not Found

    (Sorry, but someone had to do it)

    Reminds me of the gender codes the NZ Ministry of Health uses (which actually comes from Statistics New Zealand)

    M = Male F = Female U = Unknown I = Indeterminate

  • (cs) in reply to trwtf
    trwtf:
    slavik262:
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:

    In C, there is no boolean data type. That's why everyone uses int.

    Please try again. You are only wrong by 11 years. Granted, Windows and *nix, being over 11 years old, don't use it, but it still exists.

    Sorry, slavik, but he's still right. To quote from your preferred source...

    I would argue that inclusion via standard library headers would qualify as being "in the language." If not, C becomes a rather useless language that doesn't even have the ability to print output to the console.

  • fulton (unregistered) in reply to PRMan
    PRMan:
    Bobbo:
    I once worked with an in-house language which didn't have the ability to represent decimal points. So all such numbers were multiplied up by 100 or 10000 to retain the .00 or .0000 precision, then passed around/stored as needed, then divided back down for display. Genius.

    Microsoft does this for the Office 2007+ data formats because it's faster to do all the conversions, so it can't be all bad.

    I can't quite follow your reasoning... ;-)

  • clownzor (unregistered) in reply to Ouch!
    Ouch!:
    clownzor:
    Ad hominem != insult. If he had said "Your argument is wrong because you are a dumbass", that would be an ad hominem. However, he clearly listed the reasons he thought you were wrong. That is not an ad hominem, idiot.
    He wrote "ad hominem attack", which calling someone a dumbass clearly is. He didn't accuse whomever of a logical fallacy but of bad behaviour.

    Logic would like to have a word with you: http://en.wikipedia.org/wiki/Ad_hominem#Common_misconceptions

  • Jeremy Friesner (unregistered) in reply to WhiskeyJack
    WhiskeyJack:
    That's not a WTF. How else are you supposed to represent decimal numbers in a fixed-point representation?
    I think I'd want to wrap the pseudo-decimal-integers in some sort of type or class to make sure they weren't accidentally operated on as normal integers (by causing a compile-time error when misuse was detected). Otherwise the likelihood of someone accidentally adding dollars to cents (or whatnot) would be quite high.
  • Jeremy Friesner (unregistered) in reply to Gavin
    Gavin:
    Reminds me of the gender codes the NZ Ministry of Health uses (which actually comes from Statistics New Zealand)

    M = Male F = Female U = Unknown I = Indeterminate

    Well that's clearly not right. The proper way to represent gender is via normalized floating point (where 0.0f == wholly female, 1.0f == wholly male, 0.5f == perfectly hermaphrodite, and so on). "Unknown" (and/or Lady Gaga) is represented by NaN.

  • Jordan Bray (unregistered) in reply to Matt Westwood
    Matt Westwood:
    I have to share the "saysTrue" and "saysFalse" methods we wrote, which translated the multifarious ways of expressing affirmation and negation that had evolved in our various assorted "boolean valued" system environment properties as defined in our database schemas.

    They effectively boil down to:

    saysTrue: if uppercase of the first character is T or Y, return True, otherwise (which includes null or empty string) return False.

    saysFalse: if uppercase of the first character is F or N, return True, otherwise (which includes null or empty string) return False.

    Yes, the latter method gives the expected answer to "Does this string represent False or No?"

    Well it works for us, and saves a lot of repetitive mucking about.

    If it's ok for a string to be both true and false, then the solution to this WTF is obvious.

    saysTrue:
      if first character is 1
        return true
      else if the uppercase of the first character is T, Y, or N
        return true
      else if length of argument > 0
        return false
      else
        return (or throw/raise) FileNotFound
    
    saysFalse:
      if first character is 0
        return true
      else if the uppercase of the first character is F or N
        return true
      else if length of argument > 0
        return false
      else
        return (or throw/raise) FileNotFound
    

    Problem solved.

  • (cs) in reply to Jeremy Friesner
    Jeremy Friesner:
    The proper way to represent gender is via normalized floating point (where 0.0f == wholly female, 1.0f == wholly male, 0.5f == perfectly hermaphrodite, and so on). "Unknown" (and/or Lady Gaga) is represented by NaN.

    I so want to be there when someone realizes you just implied male>female.

  • (cs)

    how great would it be to have some solid, real-world technologies like CICS (which probably has something to do with Cisco) and VSAM (Virtual Something Something Something... clearly a cutting-edge technology

    Dude accepts a job, the description of which includes a list of technologies, and he doesn't research what the technologies are? He not only deserves spaghetti code, he deserves to be bitch-slapped with spaghetti noodles.

  • (cs)

    "F"illed "N"ull

    .. it all depends on the context, now, does it?

  • Allister (unregistered) in reply to Rottweiler
    Rottweiler:
    Kevin:
    AS/400s are actually kind of nice. They are pretty stable, we have a custom POS written in RPG.

    I was once moved into a position where I had to work with an AS/400 - nothing newer than RPG3 - 6 character variables max, all caps, "Databases" were files, and use of the newfangled SQL was forbidden. Green Screen was holy, and I hightailed it out of there faster than you could mouth WTF!

    Nothing wrong with green screen. Still faster than many modern systems. As for RPG3, if you can't write a program that uses the cycle you can't call yourself a real RPG programmer. ;-)

  • Anonymous Coder (unregistered) in reply to trwtf
    <Quote> jpers' comment made me wonder if I could come up with a way to store booleans in less than a byte without making a really wtf-rific mess of it. </Quote>

    I did something similar in C the other day. (It was for a cleaner way of accessing bit fields inside of the 32bit register of some sort of peripheral.)

    The following code compiles:

    #include <stdio.h> #include <stdlib.h>

    // combining 8 bit elements // (plus 24bit placeholder) into an int static union { struct { unsigned int bit0 : 1; unsigned int bit1 : 1; unsigned int bit2 : 1; unsigned int bit3 : 1; unsigned int bit4 : 1; unsigned int bit5 : 1; unsigned int bit6 : 1; unsigned int bit7 : 1; // omitted 8 to 31 (excercise for reader :) unsigned int unused : 24; } ; unsigned int value; } bools; // Note: Asumtion unsigned int is indeed 32 bit.

    int main (void) {

    bools.value = 0; // clear all bits

    // pattern '0xa5' bools.bit0 = 1; bools.bit2 = 1; bools.bit5 = 1; bools.bit7 = 1;

    printf("hex: %02x\n",bools.value);

    // pattern '0x5a' bools.value = bools.value ^ 0xff;

    printf("hex: %02x\n",bools.value);

    // pattern '0xc3' bools.bit0 = 1; bools.bit1 = 1; bools.bit2 = 0; bools.bit3 = 0; bools.bit4 = 0; bools.bit5 = 0; bools.bit6 = 1; bools.bit7 = 1;

    printf("hex: %02x\n",bools.value);

    // works the other way 'round bools.value = 0x7e; printf("binary: %1d%1d%1d%1d%1d%1d%1d%1d\n", bools.bit7,bools.bit6,bools.bit5,bools.bit4, bools.bit3,bools.bit2,bools.bit1,bools.bit0);

    return 0; }

    gcc bool.c ./a.out

    hex: a5 hex: 5a hex: c3 binary: 01111110

    You should be able to do this (haven't tried it yet):

    if (bools.bit0 && !bools.bit1) { .... }

  • Anonymous Coder (unregistered) in reply to Anonymous Coder

    And of cause I forgot the mandatory:

    static union { struct { unsigned int is_true : 1; unsigned int is_false : 1; unsigned int file_not_found : 1; unsigned int frist : 1; unsigned int brillant : 1; } ; unsigned int value; } paula;

    ... which only works on an embedded system without a filesystem.

    SCNR :)

  • Jimmy Jones (unregistered) in reply to Bobbo
    Bobbo:
    I once worked with an in-house language which didn't have the ability to represent decimal points. So all such numbers were multiplied up by 100 or 10000 to retain the .00 or .0000 precision, then passed around/stored as needed, then divided back down for display.

    Genius.

    If it prevented idiots from trying to use floating point numbers for financial calculations then I say it was a good thing.

  • English Man (unregistered) in reply to Bobbo
    Bobbo:
    I once worked with an in-house language which didn't have the ability to represent decimal points. So all such numbers were multiplied up by 100 or 10000 to retain the .00 or .0000 precision, then passed around/stored as needed, then divided back down for display.

    Genius.

    As already mentioned this is fixed-point math, used a lot in older graphics programming where you had to screw every single CPU cycle out of the ultra-tight loop that rendered each pixel. A language that doesn't support floating point though, that's crappy.

  • (cs)
    Now as you may know, COBOL doesn't any have Boolean types
    No I didn't. And now you've increased my knowledge of COBOL, which is a Bad Thing (and the capitalisation is relevant, mind).

    Anyway, who needs Booleans? If Oracle doesn't need them, nobody does.

    [goes back to working on PL/SQL project and banging head against wall]

  • (cs) in reply to nobody
    nobody:
    Nope. Age does not convert wine to vinegar. Exposure to oxygen does. Have you never considered the fact that the best wines are aged by many years?

    Exposure to oxygen alone does not cause wine to turn to vinegar. It will cause oxidation only.

    To get vinegar you need to have an additional micro organism - acetobacter (mother of vinegar)

    fruit juice + yeast = wine wine + acetobacter = vinegar

  • Anonymous (unregistered) in reply to jpers36
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    dumbass

    Sorry, I refuse to continue any discussion after an ad hominem attack.

    I really don't want to wade into this nonsense but for the sake of my own sanity (and to prevent you looking like an idiot in future arguments) I have to point out that this is not an ad hominem attack. This is just good old-fashioned name calling and you truly make yourself sound stupid by breathlessly blurting out "ad hominem!" just because someone insulted you. No disrespect or anything but this is a pet hate of mine; people seem to think it makes them sound smart but if you get the fundamental definition wrong then you sound anything but smart. In this internet age it would only take you thirty seconds to look up the definition so I really don't see you have any reason to get it wrong. Here, I'll even save you some time: http://en.wikipedia.org/wiki/Ad_hominem. Good luck in future arguments and be sure to use your new-found knowlege wisely!

  • Anonymous (unregistered) in reply to Jeremy Friesner
    Jeremy Friesner:
    Well that's clearly not right. The proper way to represent gender is via normalized floating point (where 0.0f == wholly female, 1.0f == wholly male, 0.5f == perfectly hermaphrodite, and so on). "Unknown" (and/or Lady Gaga) is represented by NaN.
    I've never understood why people think Lady Gaga is a man. She's clearly just a horrifically ugly woman or, very possibly, a bridge troll.
  • Someone who can't be bothered to login from work (unregistered)

    If the code was written in the 60s and was running on an AS/400 they had at least done a hardware upgrade at some point, which is more than a lot of places manage.

    Presumably sometime before the 2000 when IBM started trying to give it modern sounding name.

  • HardWareMeltsMyBrain (unregistered)

    Looking at all of this reminds me of one of the boolean logical bit types in the VHDL language (which although defined by the US DoD gets used in Europe while the US uses Verilog ..) :

    quote Wikipedia ...

    The primary data type std_ulogic (standard unresolved logic) consists of nine character literals in the following order[1]:

    'U' - uninitialized

    'X' - strong drive, unknown logic value

    '0' - strong drive, logic zero

    '1' - strong drive, logic one

    'Z' - high impedance

    'W' - weak drive, unknown logic value

    'L' - weak drive, logic zero

    'H' - weak drive, logic one

    '-' - don't care

    And then there are resolution functions which says what the result will be when a weak 'logic zero' meets a strong 'logic zero'

  • tristi (unregistered) in reply to nobody
    nobody:
    Someone Who Couldn't be Bothered to Log On from Work:
    1. It is impossible to store a boolean in anything less than a byte because COMPUTERS are incapable of addressing a smaller portion of memory than that. Point destroyed.
    Bitmask, douchewaffle. Google it.
    You can use bitmasks on systems with addressing by byte. But the main point here is that not everything is x86 and in embedded systems it is quite common to be able to use bit addressing.
    nobody:
    2. Why would boolean comparisons take any longer than character comparisons? Either one is an AND instruction at the machine level and a check if a register is set afterwards. Point destroyed.
    Because you have to load the byte (which contains your bit and 7 other bit variables) and then mask out your bit and then compare it. Google it.
    Not necessarily. I think that

    CMP var, 'F' JNZ IsTrue

    AND var,0x4 JNZ IsTrue

    will both take a couple of cycles in an intel processor.

  • Design Pattern (unregistered) in reply to robbak
    robbak:
    Remember, you cannot load less than a byte on a processor. indeed, you cannot load less than 4 bytes!
    That actually is 4 Bits, not 4 bytes!

    CAPTCHA: abbas - as if one of them wouldn't be enoug to let your ears bleed!

  • Someone who can't be bothered to login from work (unregistered) in reply to Rottweiler
    Rottweiler:
    Kevin:
    AS/400s are actually kind of nice. They are pretty stable, we have a custom POS written in RPG.

    I was once moved into a position where I had to work with an AS/400 - nothing newer than RPG3 - 6 character variables max, all caps, "Databases" were files, and use of the newfangled SQL was forbidden. Green Screen was holy, and I hightailed it out of there faster than you could mouth WTF!

    Didn't the AS/400 come with DB2/400 RDBMS?

  • King Zog (unregistered)

    Please stop knocking AS/400s and mainframe ... you know all that cool suff you have now: machine virtualisation, multitasking, instruction set virtualisaton etc etc etc...OS/360 did it all (and in 16K!)

    Give me an AS/400 any day!

    Zog -- still mourning the good old days of Sun ... the SparcStation 1 ... what a beast!

  • ANSI C (unregistered) in reply to slavik262
    I would argue that inclusion via standard library headers would qualify as being "in the language." If not, C becomes a rather useless language that doesn't even have the ability to print output to the console.

    IMHO, printing output to the console should not be considered a feature of the "language", but instead, a responsibility of the "operating system". After all, assembly doesn't have any way to print to a console either... it's done through an interrupt to the OS.

    A language isn't portable if it relies on the assumption that it is running on a particular type of machine, whether that is a PC or a remote control car (which shouldn't have a console for output, by the way). That's where the beauty of C comes from - it's portable assembly.

Leave a comment on “Boolean Truths”

Log In or post as a guest

Replying to comment #:

« Return to Article