• (cs)

    I wonder what the position names are. I'm guessing the code for setting them looks something like:

    strcpy (pWidget->m_sPositionName_1, "position_1.4_Degrees");
strcpy (pWidget->m_sPositionName_2, "position_2.9_Degrees");
strcpy (pWidget->m_sPositionName_3, "position_4.3_Degrees");
...
strcpy (pWidget->m_sPositionName_0, "position_0_or_360_Degrees");
.
  • Machtyn (unregistered)

    I'm sure that even an embedded no file file system would want efficiency. Efficiency, in this case, gouged its eyes out, jammed pencils in its ears, and stuffed cotton up its nose, then crawled with its unmutilated arm and leg to the nearest pool to drown itself.

  • (cs)

    Whilst the code seems pretty ghastly, I'm more surprised to see that the encoded positions seem to use straight binary rather than Gray code. It may be that the encoded position does indeed use Gray code and this code performs the conversion in a rather clumsy fashion.

  • AB (unregistered)

    Bonus points for the octal specifier in the sea of decimal specifiers. Happens to do the right thing, but wait until someone adds a zero before one of the other values!

  • Ahem (unregistered)

    To everyone who doesn't get it:

    The numbers in the defines aren't in binary.

    1001 is one thousand and one, not nine.

  • Ibix (unregistered)

    All your base are belong to us!

    Well, at least base 2 and base 10. And our grip on 2 isn't that strong.

  • Schol-R-LEA (unregistered)

    Aside from the main WTF, you have this pair of gems:

    int bit0 = DIO_Input & 1;
int bit1 = DIO_Input & 2;
int bit2 = DIO_Input & 4;
int bit3 = DIO_Input & 8;

// normalize
if (bit0 != 0) bit0 = 1;
if (bit1 != 0) bit1 = 1;
if (bit2 != 0) bit2 = 1;
if (bit3 != 0) bit3 = 1;

    What really blows my mind is that the author of this travesty apparently knew something about the bitwise operators (as the bitwise AND is used in the initialization) but didn't know how to manipulate a binary value as a binary value.

    Ow, ow, ow, ow, my poor, sore brainmeats.

  • Vilx- (unregistered)

    I'll never again look at the humble computer mouse the same way!

  • Bernhardus (unregistered)

    So the code extracts the four bits from the input number DIO_Input, then converts it to the binary representation in decimal. Finally the data member nCurrentPosition is assigned the actual value.

    What is interesting is that DIO_Input already contains the actual value; there isn't even a need to fiddle with the bits! The code above can be replaced by the following two lines (assuming m_sPositionName is an appropriately initialized array):

    pWidget->nCurrentPosition = DIO_Input; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

  • Wigy (unregistered)

    The real WTF is that the notches do not use Gray code, so it is quite possible that if you turn the wheel slowly, you get 0 -> 1 -> 0 -> 2 -> 3 -> 7 -> 4 for example.

  • Robo (unregistered) in reply to Schol-R-LEA
    Schol-R-LEA:
    Aside from the main WTF, you have this pair of gems: 
    int bit0 = DIO_Input & 1;
int bit1 = DIO_Input & 2;
int bit2 = DIO_Input & 4;
int bit3 = DIO_Input & 8;

// normalize
if (bit0 != 0) bit0 = 1;
if (bit1 != 0) bit1 = 1;
if (bit2 != 0) bit2 = 1;
if (bit3 != 0) bit3 = 1;

    What really blows my mind is that the author of this travesty apparently knew something about the bitwise operators (as the bitwise AND is used in the initialization) but didn't know how to manipulate a binary value as a binary value.

    Ow, ow, ow, ow, my poor, sore brainmeats.

    That is exactly what I was thinking as I read this. So close, yet so very, very, very far away =(

  • (cs)

    [frown]

  • ted (unregistered)

    So, about 500 more posers are going to show us how smart they are that they've heard of Gray codes. My God, you made it through your freshman year of CS. Give yourself a fucking cookie and STFU.

  • Timewarp (unregistered) in reply to Ibix
    Ibix:
    All your base are belong to us!

    Well, at least base 2 and base 10. And our grip on 2 isn't that strong.

    Featured comment please!

  • Mijzelf (unregistered)

    This is sloppy code. #define POS_0 0 #define POS_1 01 #define POS_2 10 #define POS_3 11 #define POS_4 100 should of course have been #define POS_0 0 #define POS_1 1 #define POS_2 10 #define POS_3 11 #define POS_4 100

  • NoAstronomer (unregistered) in reply to Ahem
    Ahem:
    To everyone who doesn't get it:

    The numbers in the defines aren't in binary.

    1001 is one thousand and one, not nine.

    Not even that. It's a #define. So in some places itmay be one thousand and one. In other places it could be nine. Or not.

  • rfoxmich (unregistered)

    What do you want to bet that the first version of this read:

    #define POS_0 0000 #define POS_1 0001 #define POS_2 0010 #define POS_3 0011 #define POS_4 0100 #define POS_5 0101 #define POS_6 0110 #define POS_7 0111 #define POS_8 1000 #define POS_9 1001

    and that the author had to ask someone why that did not produce the desired results?

  • Silent Penguin (unregistered) in reply to Ahem

    Thats what the line 

    Position = 1000bit3 + 100bit2 + 10*bit1 + bit0;
    is for silly!

  • bcs (unregistered)

    What they should have done is define a series of macros that convert the Decimal Binary constants into Binary Binary constants and used those in the switch statement. :b

  • (cs)

    TRWTF is thinking that TRWTF has anything to do with binary at all here.

  • (cs)

    Hey, anybody heard of Gray code? Just checking.

  • (cs) in reply to operagost
    operagost:
    Hey, anybody heard of Gray code? Just checking.

    Bit of a grey herring, if you ask me...

  • Schol-R-LEA (unregistered)

    A real kick in the mouse balls, this is.

    CAPTCHA: ingenium - such an ingenious waste of effort...

  • Doug (unregistered) in reply to NoAstronomer
    NoAstronomer:
    Ahem:
    To everyone who doesn't get it:

    The numbers in the defines aren't in binary.

    1001 is one thousand and one, not nine.

    Not even that. It's a #define. So in some places itmay be one thousand and one. In other places it could be nine. Or not.

    Uh, no.

    The only way you can get POS_9 to act like anything but "one thousand and one" is to prefix it to change the base:

    0x1001 (four thousand and ninety-seven) 01001 (five hundred and thirteen)

    Some compilers support 0b as a prefix for binary literals, but that's not standard.

    Here's the interesting part that blows your comment away: it's really, really hard to put that prefix on accidentally: "0x POS_9" and "0xPOS_9" won't compile. However, you can do:

    #define PREFIX_X(x,y) x##y #define PREFIX(x,y) PREFIX_X(x,y) int x = PREFIX(0x,POS_9); /* x=0x1001 by preprocessor magic */

    I would say that's pretty obvious that you're making it hex, though, even if the preprocessor magic is counter intuitive.

    So, no -- POS_9 is always "one thousand and one" even though it's a define.

  • QJo (unregistered)

    The real WTF, in case anyone hasn't figured it out yet, is that the programmer didn't convert the pattern of 1's and 0's into a string, and then use the strpos function (or whatever it's called) to extract the relevant information.

  • (cs)

    Why doesn't this code use XML? It seems like the next logical step.

  • verisimilidude (unregistered)

    I am reminded of: There are 10 kinds of people in the world: those that understand binary and those that don't

  • doctor_of_common_sense (unregistered)

    hah! i love C and think all those who flee from C or C++ are meeps and weepy pants, but I still would like to nominate the author of this hilarity to be "most likely shoot themselves in the foot and a lot of stuff around them in the next 5 minutes".

  • Medinoc (unregistered)

    I was about to comment on the lack of Gray code, but it was so obvious other people already said it.

  • Anon (unregistered) in reply to rfoxmich
    rfoxmich:
    What do you want to bet that the first version of this read:

    #define POS_0 0000 #define POS_1 0001 #define POS_2 0010 #define POS_3 0011 #define POS_4 0100 #define POS_5 0101 #define POS_6 0110 #define POS_7 0111 #define POS_8 1000 #define POS_9 1001

    and that the author had to ask someone why that did not produce the desired results?

    Very high, I suspect, but that's more of a C WTF to be honest.

    I'd have far preferred something like a 0o765 syntax (c.f. 0xfed). A 0b1010 syntax might also have merit (for example it would have made for easier reading if the suggested Gray code were used), though if you can't translate hex to binary in your head, then you've no business working with such things.

  • (cs) in reply to Medinoc
    Medinoc:
    I was about to comment on the lack of Gray code, but it was so obvious other people already said it.

    Yet you still felt compelled to post about it anyway... Good jorb!

  • (cs) in reply to Schol-R-LEA
    Schol-R-LEA:
    Aside from the main WTF, you have this pair of gems: 
    int bit0 = DIO_Input & 1;
int bit1 = DIO_Input & 2;
int bit2 = DIO_Input & 4;
int bit3 = DIO_Input & 8;

    // normalize
if (bit0 != 0) bit0 = 1;
if (bit1 != 0) bit1 = 1;
if (bit2 != 0) bit2 = 1;
if (bit3 != 0) bit3 = 1;
    Aside from the hilarity of a page-long solution for a three liner problem, the "normalization" part could be rolled into the bit extraction in either of the following ways:

    bool bit0 = DIO_Input & 1;
//or
int bit0 = !!(DIO_Input & 1);
  • Jupiter (unregistered)

    oh c'mon - who hasn't done something like this?!

  • Ken B. (unregistered)

    Everyone's heard of BCD arithmetic. It takes a pure genius to come up with the concept to DCB arithmetic.

  • (cs) in reply to Doug
    Doug:
    Here's the interesting part that blows your comment away: it's really, really hard to put that prefix on accidentally: "0x POS_9" and "0xPOS_9" won't compile. However, you can do:

    #define PREFIX_X(x,y) x##y #define PREFIX(x,y) PREFIX_X(x,y) int x = PREFIX(0x,POS_9); /* x=0x1001 by preprocessor magic */

    I would say that's pretty obvious that you're making it hex, though, even if the preprocessor magic is counter intuitive.

    So, no -- POS_9 is always "one thousand and one" even though it's a define.

    That's where user defined literals in C++ 11 (née 0x) come handy.
    #include <iostream>
constexpr int operator ""b (const char *s, size_t n) {
int r = 0;
while (n--) {
static_assert(s[n] == '1' || s[n] == '0');
if (s[n] == '1') r |= 1;
r = r << 1;
}
return r;
}
int main()
{
cout << 1001b << endl; // outputs 9
}
    Unfortunately, no shipping version of gcc can compile this AFAIK

    Addendum (2011-06-27 09:05): As was correctly pointed out, the correct code inside of while should be

        static_assert(s[n] == '1' || s[n] == '0');
    r = r << 1;
    if (s[n] == '1') r |= 1;

    It was a classic off-by-one in disguise.

  • (cs) in reply to Bernhardus
    Bernhardus:
    So the code extracts the four bits from the input number DIO_Input, then converts it to the binary representation in decimal. Finally the data member nCurrentPosition is assigned the actual value.

    What is interesting is that DIO_Input already contains the actual value; there isn't even a need to fiddle with the bits! The code above can be replaced by the following two lines (assuming m_sPositionName is an appropriately initialized array):

    pWidget->nCurrentPosition = DIO_Input; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Thank you, Mr. Obvious.
  • (cs)

    There are 10 types of people:

    • Those who understand binary
    • Those who don't
  • (cs) in reply to ParkinT
    ParkinT:
    There are 10 types of people: - Those who understand binary - Those who don't

    OMG LOL, I never heard that before! Did you just make that up? Ok, I'm done now, sorry

  • Doug (unregistered) in reply to ParkinT
    ParkinT:
    There are 10 types of people: - Those who understand binary - Those who don't
    - And those who mistake it for ternary
  • Bob (unregistered)

    For a moment I thought maybe they somehow made the compiler treat integer literals as binary, but then there's this:

    int bit0 = DIO_Input & 1;
int bit1 = DIO_Input & 2;
int bit2 = DIO_Input & 4;
int bit3 = DIO_Input & 8;
  • (cs) in reply to ted
    ted:
    So, about 500 more posers are going to show us how smart they are that they've heard of Gray codes.
    Bullshit. None of the articles on this site get that many comments.

    Your estimate is way off.

  • (cs) in reply to boog
    boog:
    ted:
    So, about 500 more posers are going to show us how smart they are that they've heard of Gray codes.
    Bullshit. None of the articles on this site get that many comments.

    Your estimate is way off.

    You're wrong. There are that many posts, but we're silenced by the forum admins who keep deleting gems like "No, YOUR a racist loser!"

  • Third Normal (unregistered)
    // normalize
    Shouldn't there be a round-trip to a database along in here somewhere?
  • Meep (unregistered) in reply to rfoxmich
    rfoxmich:
    What do you want to bet that the first version of this read:

    #define POS_0 0000 #define POS_1 0001 #define POS_2 0010 #define POS_3 0011 #define POS_4 0100 #define POS_5 0101 #define POS_6 0110 #define POS_7 0111 #define POS_8 1000 #define POS_9 1001

    and that the author had to ask someone why that did not produce the desired results?

    Because TRWTF is that we still use a prank language designed by those nutty neckbeards Kernighan and Ritchie.

    Seriously: leading 0's change the base? 0x is fine, but there should be 0o or 0c for octal. A straight 0 is just nuts.

  • (cs) in reply to RogerC
    RogerC:
    Bernhardus:
    So the code extracts the four bits from the input number DIO_Input, then converts it to the binary representation in decimal. Finally the data member nCurrentPosition is assigned the actual value.

    What is interesting is that DIO_Input already contains the actual value; there isn't even a need to fiddle with the bits! The code above can be replaced by the following two lines (assuming m_sPositionName is an appropriately initialized array):

    pWidget->nCurrentPosition = DIO_Input; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Thank you, Mr. Obvious.
    Not only obvious, but probably incorrect too. All of the systems of this type I've worked with expose eight input values as bits of a byte. The low four bits correspond to the output of the wheel sensor, but the other four could be used for anything. This is a classic case of Muphry's Law.
  • (cs) in reply to Jaime
    Jaime:
    RogerC:
    Bernhardus:
    So the code extracts the four bits from the input number DIO_Input, then converts it to the binary representation in decimal. Finally the data member nCurrentPosition is assigned the actual value.

    What is interesting is that DIO_Input already contains the actual value; there isn't even a need to fiddle with the bits! The code above can be replaced by the following two lines (assuming m_sPositionName is an appropriately initialized array):

    pWidget->nCurrentPosition = DIO_Input; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Thank you, Mr. Obvious.
    Not only obvious, but probably incorrect too. All of the systems of this type I've worked with expose eight input values as bits of a byte. The low four bits correspond to the output of the wheel sensor, but the other four could be used for anything. This is a classic case of Muphry's Law.
    pWidget->nCurrentPosition = DIO_Input & 15; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Better?

  • Grammar Nazi Prick (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    boog:
    ted:
    So, about 500 more posers are going to show us how smart they are that they've heard of Gray codes.
    Bullshit. None of the articles on this site get that many comments.

    Your estimate is way off.

    You're wrong. There are that many posts, but we're silenced by the forum admins who keep deleting gems like "No, YOUR a racist loser!"

    FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU!

  • (cs) in reply to verisimilidude
    verisimilidude:
    I am reminded of: There are 10 kinds of people in the world: those that understand binary and those that don't

    According to the code that was posted there should be 11 kinds of people that understand binary, those that do, those that don't and those that think they do.

  • Meep (unregistered) in reply to Kuba
    Kuba:
    Doug:
    Here's the interesting part that blows your comment away: it's really, really hard to put that prefix on accidentally: "0x POS_9" and "0xPOS_9" won't compile. However, you can do:

    #define PREFIX_X(x,y) x##y #define PREFIX(x,y) PREFIX_X(x,y) int x = PREFIX(0x,POS_9); /* x=0x1001 by preprocessor magic */

    I would say that's pretty obvious that you're making it hex, though, even if the preprocessor magic is counter intuitive.

    So, no -- POS_9 is always "one thousand and one" even though it's a define.

    That's where user defined literals in C++ 11 (née 0x) come handy.
    #include <iostream>
constexpr int operator ""b (const char *s, size_t n) {
int r = 0;
while (n--) {
static_assert(s[n] == '1' || s[n] == '0');
if (s[n] == '1') r |= 1;
r = r << 1;
}
return r;
}
int main()
{
cout << 1001b << endl; // outputs 9
}
    Unfortunately, no shipping version of gcc can compile this AFAIK

    Link to FAQ, that's pretty neat.

    Looks like they just give you one of the existing literal tokens as a string so they don't have to make the lexer dynamic, which makes sense. Unfortunately, it means you can't do a literal form for sets or lists, and you have to use namespaces to avoid clashes.

  • (cs) in reply to boog
    boog:
    Jaime:
    RogerC:
    Bernhardus:
    So the code extracts the four bits from the input number DIO_Input, then converts it to the binary representation in decimal. Finally the data member nCurrentPosition is assigned the actual value.

    What is interesting is that DIO_Input already contains the actual value; there isn't even a need to fiddle with the bits! The code above can be replaced by the following two lines (assuming m_sPositionName is an appropriately initialized array):

    pWidget->nCurrentPosition = DIO_Input; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Thank you, Mr. Obvious.
    Not only obvious, but probably incorrect too. All of the systems of this type I've worked with expose eight input values as bits of a byte. The low four bits correspond to the output of the wheel sensor, but the other four could be used for anything. This is a classic case of Muphry's Law.
    pWidget->nCurrentPosition = DIO_Input & 15; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Better?

    No. That comment wasn't about the code being wrong, it was about Bernhardus providing a fix but putting as little thought into it as the original developer did and making a classic re-write mistake. It's a good idea to not re-write WTFy but functional code without giving it a good deal of thought because new bugs are often introduced.

Leave a comment on “Decimal Binary”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article