I mean is it really a waste? What's minimum amount of bits most CPUs read in one cycle.
this post was submitted on 15 May 2025
1159 points (98.7% liked)
Programmer Humor
23431 readers
424 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
In terms of memory usage it's a waste. But in terms of performance you're absolutely correct. It's generally far more efficient to check is a word is 0 than to check if a single bit is zero.
load more comments
(1 replies)
I swore I read that mysql dbs will store multiple bools in a row as bit maps in one byte. I can't prove it though
load more comments
(2 replies)
We need to be able to express 0 and 1 as integers so that functionality is just being overloaded to express another concept.
Wait until the person who made this meme finds out about how many bits are being wasted on modern CPU architectures. 7 is the minimum possible wasted bits but it would be 31 on every modern computer (even 64b machines since they default to 32b ints).
boolean bloat
I first thought you wrote boolean float, not sure if that's even worse.
pragma(pack) {
int a:1, b:1, ... h:1;
}
IIRC.
Are you telling me that no compiler optimizes this? Why?
CPUs don't read one bit a a time.
Consider what the disassembly would look like. There's no fast way to do it.
It's also unnecessary since 8 bytes is a negligible amount in most cases. Serialization is the only real scenario where it matters. (Edit: and embedded)
In embedded, if you are to the point that you need to optimize the bools to reduce the footprint, you fucked up sizing your mcu.
It would be slower to read the value if you had to also do bitwise operations to get the value.
But you can also define your own bitfield types to store booleans packed together if you really need to. I would much rather that than have the compiler do it automatically for me.
Well there are containers that store booleans in single bits (e.g. std::vector<bool> - which was famously a big mistake).
But in the general case you don't want that because it would be slower.
Why is this a big mistake? I’m not a c++ person
The mistake was that they created a type that behaves like an array in every case except for bool, for which they created a special magical version that behaves just subtly different enough that it can break things in confusing ways.
load more comments
(1 replies)
In the industrial automation world and most of the IT industry, data is aligned to the nearest word. Depending on architecture, that's usually either 16, 32, or 64 bits. And that's the space a single Boolean takes.
That's why I primarily use booleans in return parameters, beyond that I'll try to use bitfields. My game engine's tilemap format uses a 32 bit struct, with 16 bit selecting the tile, 12 bit selecting the palette, and 4 bit used for various bitflags (horizontal and vertical mirroring, X-Y axis invert, and priority bit).
Bit fields are a necessity in low level networking too.
They're incredibly useful, I wish more people made use of them.
I remember I interned at a startup programming microcontrollers once and created a few bitfields to deal with something. Then the lead engineer went ahead and changed them to masked ints. Because. The most aggravating thing is that an int size isn't consistent across platforms, so if they were ever to change platforms to a different word length, they'd be fucked as their code was full of platform specific shenanigans like that.
/rant
I always use stdint.h so that my types are compatible across any mcu. And it makes the data type easily known instead of guessing an i t size
Good rant.
Yeah. I once had to do stuff to code that had bit-fields like that and after a while, realised (by means of StackOverflow) that that part is UB and I had to go with bitwise operations instead.
load more comments
(1 replies)
3GPP has an interesting way of serialising bools on the wire with ASN.1
NULL OPTIONAL
meaning only the type would be stored if true, otherwise it won't be set at all
That requires some form of self describing format and will probably look like a sparse matrix in the end.
Pl/1 did it right:
Dcl 1 mybools, 3 bool1 bit(1) unaligned, 3 bool2 bit(1) unaligned, … 3 bool8 bit(1) unaligned;
All eight bools are in the same byte.