1168
Tell me the truth ... (europe.pub)
submitted 1 year ago by to c/programmer_humor@programming.dev
170 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 1 year ago (6 children)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 0 points 1 year ago (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 1 year ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 0 points 1 year ago (3 children)

    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_t is not 2 bytes because it is sometimes followed by padding?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 0 points 1 year ago* (2 children)

    a bool is actually a single bit, the rest is all padding

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 1 year ago (1 child)

    It is not. A bool in C, C++, Rust, Go, and every language that I know is 1 byte. Why are you arguing this basic very well known fact so much?

    Just say "oh I was mistaken, TIL". It's not shameful.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 0 points 1 year ago

    because with things that the compiler does, like padding for alignment, it frequently takes up more space than that. that was my argument the whole time. what til are you talking about? I'm talking about an extra layer you've decided doesn't count. ofc sizeof bool will be a byte in all of those languages.

    a bool taking up a single byte is a fantasy that those languages use because developers generally don't need to think about all the other stuff going on.

  • permalink
  • fedilink
  • source
  • parent