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.
Back in the day when it mattered, we did it like
#define BV00 (1 << 0)
#define BV01 (1 << 1)
#define BV02 (1 << 2)
#define BV03 (1 << 3)
...etc
#define IS_SET(flag, bit) ((flag) & (bit))
#define SET_BIT(var, bit) ((var) |= (bit))
#define REMOVE_BIT(var, bit) ((var) &= ~(bit))
#define TOGGLE_BIT(var, bit) ((var) ^= (bit))
....then...
#define MY_FIRST_BOOLEAN BV00
SET_BIT(myFlags, MY_FIRST_BOOLEAN)
Okay. Gen z programmer here. Can you explain this black magic? I see it all the time in kernel code but I have no idea what it means.
The code is a set of preprocessor macros to stuff loads of booleans into one int (or similar), in this case named 'myFlags'. The preprocessor is a simple (some argue too simple) step at the start of compilation that modifies the source code on its way to the real compiler by substituting #defines, prepending #include'd files, etc.
If myFlags is equal to, e.g. 67, that's 01000011, meaning that BV00, BV01, and BV07 are all TRUE and the others are FALSE.
The first part is just for convenience and readability. BV00 represents the 0th bit, BV01 is the first etc. (1 << 3) means 00000001, bit shifted left three times so it becomes 00001000 (aka 8).
The middle chunk defines macros to make bit operations more human-readable.
SET_BIT(myFlags, MY_FIRST_BOOLEAN) gets turned into ((myFlags) |= ((1 << 0))) , which could be simplified as myFlags = myFlags | 00000001 . (Ignore the flood of parentheses, they're there for safety due to the loaded shotgun nature of the preprocessor.)
It's called bitshifting and is used to select which bits you want to modify so you can toggle them individually.
1 << 0 is the flag for the first bit
1 << 1 for the second
1 << 2 for the third and so on
I think that's correct. It's been years since I've used this technique tbh 😅
With embedded stuff its still done like that. And if you go from the arduino functionss to writing the registers directly its a hell of a lot faster.
Wait till you find out about alignment and padding
Tell me the truth, i can handle it
I set all 8 bits to 1 because I want it to be really true.
01111111 = true
11111111 = negative true = false
Could also store our bools as floats.
00111111100000000000000000000000 is true and 10111111100000000000000000000000 is negative true.
Has the fun twist that true & false is true and true | false is false .
So all this time true was actually false and false was actually true ?
Depends on if you are on a big endian or little endian architecture.
Come on man, I’m not gonna talk about my endian publicly
00001111 = maybe
10101010 = I don’t know
0011 1111 = could you repeat the question
Schrödingers Boolean
Why do alternative facts always gotta show up uninvited to the party? 🥳
Depending on the language
And compiler. And hardware architecture. And optimization flags.
As usual, it's some developer that knows little enough to think the walls they see around enclose the entire world.
I don't think so. Apart from dynamically typed languages which need to store the type with the value, it's always 1 byte, and that doesn't depend on architecture (excluding ancient or exotic architectures) or optimisation flags.
Which language/architecture/flags would not store a bool in 1 byte?
things that store it as word size for alignment purposes (most common afaik), things that pack multiple books into one byte (normally only things like bool sequences/structs), etc
things that store it as word size for alignment purposes
Nope. bools only need to be naturally aligned, so 1 byte.
If you do
struct SomeBools {
bool a;
bool b;
bool c;
bool d;
};
its 4 bytes.
sure, but if you have a single bool in a stack frame it's probably going to be more than a byte. on the heap definitely more than a byte
but if you have a single bool in a stack frame it’s probably going to be more than a byte.
Nope. - if you can't read RISC-V assembly, look at these lines
sb a5,-17(s0)
...
sb a5,-18(s0)
...
sb a5,-19(s0)
...
That is it storing the bools in single bytes. Also I only used RISC-V because I'm way more familiar with it than x86, but it will do the same thing.
on the heap definitely more than a byte
Nope, you can happily malloc(1) and store a bool in it, or malloc(4) and store 4 bools in it. A bool is 1 byte. Consider this a TIL moment.
c++ guarantees that calls to malloc are aligned https://en.cppreference.com/w/cpp/memory/c/malloc .
you can call malloc(1) ofc, but calling malloc_usable_size(malloc(1)) is giving me 24, so it at least allocated 24 bytes for my 1, plus any tracking overhead
yeah, as I said, in a stack frame. not surprised a compiler packed them into single bytes in the same frame (but I wouldn't be that surprised the other way either), but the system v abi guarantees at least 4 byte alignment of a stack frame on entering a fn, so if you stored a single bool it'll get 3+ extra bytes added on the next fn call.
computers align things. you normally don't have to think about it. Consider this a TIL moment.