You're viewing a single thread.
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, 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.
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
Indeed. Padding exists. A bool is still one byte.
it’ll get 3+ extra bytes added on the next fn call.
...of padding. Jesus. Are you going to claim that
uint16_tis not 2 bytes because it is sometimes followed by padding?
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?
I think he's talking about if a variable only exists in registers. In which case it is the size of a register. But that's true of everything that gets put in registers. You wouldn't say
uint16_tis word-sized because at some point it gets put into a word-sized register. That's dumb.