• Decius (unregistered)

    When all you have is a hammer, everything looks like a nail.

    And when all you see is nails, every tool looks like a hammer.

    But sometimes you have a hammer and need to drive a nail.

  • LCrawford (unregistered)

    This is a ~Frist comment, but I thought the result of (selectedExtra &= ~DRYER_EXTRA_1;) was going to later miraculously work because a wrong bit was tested.

  • WhatEver (unregistered)

    I disagree that bit masks are hard - they only require understanding 3 basic operations (And, Or, Not). What this post shows is an absence of quality control. Any level of testing should have shown that this code would fail.

  • stanThe (unregistered)

    just dump bit masks for booleans, and use a few extra bytes. memory is EXTREMELY cheap nowadays.

  • kktkkr (unregistered)

    There's no doubt you can't fail to avoid cutting your losses, so let's just call it a wash.

  • beef (unregistered) in reply to stanThe

    Memory is not always cheap! I just had to replace a bunch of byte arrays with bitmasks since the icons they represented would not fir on the MCU we were using. Beyond that, there are so many other reasons for doing this that have nothing to do with size. Just imagine the "options" being set through DIP switched on a 16-bit port...

  • El Dorko (unregistered) in reply to stanThe

    You say that, but this is a dryer or some such; embedded thingamawhatsits may have very limited amount of memory available. That said, this nonsense probably wastes more memory than a simple set of booleans...

  • Brian (unregistered)

    "Memory is cheap nowadays" says the guy who's not in charge of figuring out how to reduce the footprint of a data-intensive process that eats GBs of RAM for a midnight snack, so that the system can run multiple instances of this process at a time.

  • D-Coder (unregistered) in reply to Decius

    And when all you have is a three-headed hammer, everything looks like three nails.

    This though was inspired by an actual boss of mine.

  • (nodebb)

    Some of us write code that still has to fit in 32kB. Maybe in a few years we'll get some better hardware and we'll be able to use 33kB.

    That's inflation.

  • (nodebb) in reply to dkf

    The problem with having only 32KB is that most people want features that require 64GB, and that's not possible. Otherwise, it's just code that does its job and fits in a small box.

  • Mischa (unregistered)

    Some languages (C++) optimize a vector of booleans into a bitset, no need for bitmasks

  • boy-o (unregistered)

    Some of us write code in languages whose compilers are smart enough to figure out that arrays of booleans can be packed and implemented with bitmasks, and never have to worry about any of this.

  • RichP (unregistered)

    Heh. There is a nonzero chance that we bid on and lost this project. Not so say we wouldn't have created our own WTFs, but I do understand bitmasks (and how to count up from 1 without skipping #5).

  • Pjrz (unregistered) in reply to boy-o

    But I would never want to use a compiler that's smarter than me.

    This does limit my options quite considerable.

  • Pjrz (unregistered) in reply to boy-o

    But I would never want to use a compiler that's smarter than me.

    This does limit my options quite considerable.

  • Pjrz (unregistered)

    And now I've double-posted because the first time TDWTF told me that the CAPTCHA was invalid (despite the fact that all you have to do is tick a box). Except it obviously wasn't invalid after all.

  • (nodebb)

    Bitmasks are JustTheBeginning(TM) . I have written code in that most famous language, MATLAB, which combines parts of bytes into a less-than-16-bit word, which has to be expanded to 16 bits, then adjusted to properly convert to a signed int and then to a float. yep,
    with "loand" my own personal bitmask 0x0F .

    my_double = double( bitshift( typecast( bitshift( uint16( bitshift( bitand(uint16(in_data(7,:)), loand) , 8) ) + uint16(in_data(8,:)),4 ) ,'int16' ), -4) )

    And it all actually worked.

  • (nodebb)

    "A double negative is not a not bad idea"

    I see what you did here.

  • Alex (unregistered)

    I have a problem.

    I know, I'll use bitmasks.

    Now I have 2^n problems.

  • James (unregistered)

    In addition to all of the above, I will add that memory consumption isn't the only concern. If you're implementing a wireless protocol (e.g., Bluetooth), every extra byte you transmit over the air increases the chances of there being a bit error, so you REALLY don't want to transmit unnecessary data that has to be verified for correctness. In this scenario, I will take a bitmask of 8 bits over 8 bytes representing 8 booleans any day.

  • Worf (unregistered) in reply to boy-o

    Generally speaking, those languages are not available on hardware that's got limited amounts of RAM.

    And 32kB? Luxury. You can still get ARM MCUs with 8kB (or less!) RAM. And that was the "deluxe high RAM edition" of the MCU. You could end up with a paltry 1kB of RAM. That's only 256 32-bit things. (And ARM architecture MCUs are handy with 32-bit ints, and 32-bit pointers).

  • snoofle (unregistered) in reply to James

    To everyone assuming that a boolean will fit into a single bit, do I really need to remind you about: https://thedailywtf.com/articles/What_Is_Truth_0x3f_

  • Chris (unregistered)

    We do maths at our company, and bitmasks are our bread-and-butter for efficient calculations. However, we overuse to them point where some bitmasks are storing things such as indexes into an array of objects. For example, you might check if a mask contains object with an index / unique identifier of 3, so you do a check for (mask & (1 << 3)) > 0. I'm trying to get across that a hash set of the objects themselves may be the better way to go for that (assuming simple hash code functions), especially as it doesn't restrict you to 32 or 64 objects per bit mask. We actually had to upgrade a number of old bitmasks from 32-bit ints to 64-bit ints a few years back for that reason, and there was a bug introduced because someone made the bitmask a signed integer instead of unsigned.

    The other slightly WTF thing we do is keep a global array of bitshifted values, where BitShift[value] = 1 << value. It's not for efficiency, but for readability, and I have to admit it does improve things quite a bit.

  • (nodebb)

    I just had to replace a bunch of byte arrays with bitmasks since the icons they represented would not fir on the MCU we were using.

    Say what? The only way I could see that that would work is if the icons were black and white, represented one pixel per byte. Why would anyone use bytes for black and white pixels, wasting 7 bits?

  • bvs23bkv33 (unregistered) in reply to Decius

    When all you have is a hammer, everything looks like a junior programmer

  • RLB (unregistered) in reply to Brian

    Says, probably, the #@^&$# who wrote that memory hog in the first place.

  • Mirno (unregistered)

    Sweet Jebus - does nobody use bitfields? I'm assuming this is C because of the #defines...

    union foo { struct { unsigned long feature1 : 1; unsigned long feature2 : 1; unsigned long feature3 : 1; } fields; unsigned long raw; };

    Then it's just variable.raw = 0; variable.fields.feature1 = 1;

    Let the compiler do the work.

  • (nodebb) in reply to Mischa

    Some languages (C++) optimize a vector of booleans into a bitset, no need for bitmasks

    Nope, or at least "nope for C++". The standard library has a specialised (probably partially) version of std::vector specifically for bool, but the language itself doesn't care.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to Mirno

    Bitfields are great... until you have to support multiple architectures and find that the bit order is reversed on one of the architectures.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    The original hardware support libraries for the STM10x series of microcontrollers had a bunch of hard-coded constants with which they compared the entire I2C status register. If your I2C hardware got into a state that wasn't recognized in the list of magic cookie values, it didn't work. Actually it didn't work anyhow, and as I was working on a project that used a lot of I2C, I basically had to write my own support code from scratch.

  • HK-47 (unregistered)

    0x2b | ~0x2b

  • Kaewberg (unregistered) in reply to HK-47

    -1

  • Via Lapidea (unregistered)

    When i find a line like "if(isEnoughMoney == FALSE)" in the code, all my alarm bells start ringing.

  • (nodebb) in reply to HK-47

    " ~0x2b" Now I know who kills the poor bees... Environmentalists, protect us from that bee killer!

  • (nodebb) in reply to James

    Actually, if you have an unreliable transport layer, eight bytes are better than eight bits (if reliability outweighs bandwidth usage) because you can add redundancy. If you represent true by a byte with eight 1 bits and false with eight 0 bits, you can detect an error unless all eight bits in a byte get flipped.

Leave a comment on “Not a Not Bad Approach”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article