Wait till you here about every ascii letter. . .
what about them?
ASCII was originally a 7-bit standard. If you type in ASCII, every leading bit is always
0.At least ASCII is forward compatible with UTF-8
Ascii needs seven bits, but is almost always encoded as bytes, so every ascii letter has a throwaway bit.
Let’s store the boolean there then!!
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?
Apart from dynamically typed languages which need to store the type with the value
You know that depending on what your code does, the same C that people are talking upthread doesn’t even need to allocate memory to store a variable, right?
How does that work?
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, ormalloc(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 callingmalloc_usable_size(malloc(1))is giving me 24, so it at least allocated 24 bytes for my 1, plus any tracking overheadyeah, 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.
Fucking lol at the downvoters haha that second sentence must have rubbed them the wrong way for being too accurate.
Then you need to ask yourself: Performance or memory efficiency? Is it worth the extra cycles and instructions to put 8 bools in one byte and & 0x bitmask the relevant one?
Sounds like a compiler problem to me. :p
And you may ask yourself: where is my beautiful house? Where is my beautiful wife?
- Soon to be
- That’s me
Talking heads - once in a lifetime
Letting the days go by, let the water hold me down
A lot of times using less memory is actually better for performance because the main bottleneck is memory bandwidth or latency.
It’s not just less memory though - it might also introduce spurious data dependencies, e.g. to store a bit you now need to also read the old value of the byte that it’s in.
It might also introduce spurious data dependencies
Those need to be in the in smallest cache or a register anyway. If they are in registers, a modern, instruction reordering CPU will deal with that fine.
to store a bit you now need to also read the old value of the byte that it’s in.
Many architectures read the cache line on write-miss.
The only cases I can see, where byte sized bools seems better, are either using so few that all fit in one chache line anyways (in which case the performance will be great either way) or if you are repeatedly accessing a bitvector from multiple threads, in which case you should make sure that’s actually what you want to be doing.
Yep, and anding with a bit ask is incredibly fast to process, so it’s not a big issue for performance.
std::vector<bool>fits eight booleans into one byte.auto v = std::vector<bool>(8); bool* vPtr = v.data; vPtr[2] = true; // KABOOM !!!I’ve spent days tracking this bug… That’s how I learned about bool specialisation of std::vector.
std::vector<std::vector<bool>> is how I stored the representation of a play field for a Tetris game I made once.
I set all 8 bits to 1 because I want it to be really true.
I was programming in assembly for ARM (some cortex chip) and I kid you not the C program we were integrating with required 255, with just 1 it read it as false
TIL, 255 is the new 1.
Aka -1 >> 1 : TRUE
But only if you really mean it. If not, it’s a syntax error and the compiler will know.
01111111 = true
11111111 = negative true = false
negative true = negative non-zero = non-zero = true.
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
Why do alternative facts always gotta show up uninvited to the party? 🥳
00001111 = maybe
Schrödingers Boolean
10101010 = I don’t know
0011 1111 = could you repeat the question
100001111 = maybe not
00000001 00000000 00001111 10101010
What if it’s an unsigned boolean?
Cthulhu shows up.
Common misconception… Unsigned booleans (ubool) are always 16-bits.
Could also store our bools as floats.
00111111100000000000000000000000is true and10111111100000000000000000000000is negative true.Has the fun twist that true & false is true and true | false is false .
You jest, but on some older computers, all ones was the official truth value. Other values may also have been true in certain contexts, but that was the guaranteed one.
Joke’s on you, I always use 64 bit wide unsigned integers to store a 1 and compare to check for value.
So does the cpu
string boolEnable = "True";Violence
Maybe json is named after Jason Voorhees
Wait till you realise the size of SSD sectors
Redundancy is nice in the event of bitflip errors
Is the redundancy used for bools? I mean in actual practice.
C/C++ considers an nonzero number, as your true value but false is only zero. This would allow you to guard against going from true to false via bit flip but not false to true.
Other languages like rust define 0 to be false and 1 to be true and any other bit pattern to be invalid for bools.iunno ¯_(ツ)_/¯
This guy never coded in KEIL C on an 8051 architecture. They actually use bit addressable RAM for booleans. And if you set the compiler to pass function parameters in registers, it uses the carry flag for the first bit or bool type parameter.
Weird how I usually learn more from the humor communities than the serious ones… 😎
just like electronic components, they sell the gates by the chip with multiple gates in them because it’s cheaper
That’s a good analogy.
I have a solution with a bit fields. Now your bool is 1 byte :
struct Flags { bool flag0 : 1; bool flag1 : 1; bool flag2 : 1; bool flag3 : 1; bool flag4 : 1; bool flag5 : 1; bool flag6 : 1; bool flag7 : 1; };Or for example:
struct Flags { bool flag0 : 1; bool flag1 : 1: int x_cord : 3; int y_cord : 3; };I watched a YouTube video where a dev was optimizing unity code to match the size of data that is sent to the cpu using structs just like this.
typedef struct { bool a: 1; bool b: 1; bool c: 1; bool d: 1; bool e: 1; bool f: 1; bool g: 1; bool h: 1; } __attribute__((__packed__)) not_if_you_have_enough_booleans_t;This was gonna be my response to OP so I’ll offer an alternative approach instead:
typedef enum flags_e : unsigned char { F_1 = (1 << 0), F_2 = (1 << 1), F_3 = (1 << 2), F_4 = (1 << 3), F_5 = (1 << 4), F_6 = (1 << 5), F_7 = (1 << 6), F_8 = (1 << 7), } Flags; int main(void) { Flags f = F_1 | F_3 | F_5; if (f & F_1 && f & F_3) { // do F_1 and F_3 stuff } }You beat me to it!
Or just
std::bitset<8>for C++. Bit fields are neat though, it can store weird stuff like a 3 bit integer, packed next to booleansThat’s only for C++, as far as I can tell that struct is valid C
…or you can be coding assembler - it’s all just bits to me
