You must log in or # to comment.
I use bit masks, suck it! (Really though, programming on an embedded CPU might be reasonable to do this, depending on the situation, but on a PC, trying to not waste bits wastes time)
exactly! it is more costly for your pc cpu to check for a bit inside a byte, than just get the byte itself, because adresses only point to bytes
Unlikely. Most of the time on modern hardware, you’re going to be cache-limited, not cycle-limited. Checking one bit in a register is insanely fast.
x86 has bit manipulation instructions for any bit. If you have a book stored in bit 5 it doesn’t need to do anything masking, it can just directly check the state of bit 5. If you do masking in a low-level programming language to access individual bits then the compiler optimization will almost always change them to the corresponding bit manipulation instructions.
So there’s not even a performance impact if you’re cycle limited. If you have to operate on a large number of bools then packing 8 of them in bytes can sometimes actually improve performance, as then you can more efficiently use the cache. Though unless you’re working with thousands of bools in a fast running loop you’re likely not going to really notice the difference.
But most bool implementations still end up wasting 7 out of 8 bits (or sometimes even 15 out of 16 or 31 out of 32 to align to the word size of the device) simply because that generally produces the most readable code. Programming languages are not only designed for computers, but also for humans to work on and maintain, and waisting bits in a bool happens to be more optimal for keeping code readable and maintainable.
That bools are stored in 8 bits rather than 1 is a compiler detail. I don’t really see how this improves readability, unless you mean that of the compiled binary.
Use bit-fields:
struct { bool a : 1; bool b : 1; bool c : 1; //... };Edit: careful not to use a 1-bit signed int, since the only values are 0 and -1, not 0 and 1. This tripped me up once.
This is both the right and wrong answer
In a world where a bigger memory chip is more expensive by only a few cents where this would be most useful, is this feature still relevant?
Yes, because cache optimization is still important. Also useful to keep the size of packets down, to reduce the size of file formats, and anywhere that you use hundreds of thousands of instances of the struct.
For the packet size and fils format issues, it seems like this language feature would be less reliable than bit shifting or masking, given that different implementations may store the bits in a different order or not compactly
I’ve used it a fair amount for memory mapped IO where the hardware defined bitfields. It is also useful when you have a data format with bitfields. I’d say it is also useful when your data does not respect byte boundaries, but the only time I’ve run into that involved the bit order being “backwards”, which means that I still had to bittwidle things back together.
From a performance perspective, a cache line is only 64 bytes. Space in registers, low level memory caches, and memory throughout are all limited as well.
If you want to optimize to this point, do some embedded development. It’s somewhat fun to work at such a low level (testing tends to be annoying though)
