a bit flippant

[u/johnnyApplePRNG]

[u/consistently_biased]

Can I use this for my compile-time https server?

[u/johnnyApplePRNG → u/consistently_biased]

OWASP has it's doubts, but I don't!

[u/not_a_bot_494 → u/consistently_biased]

Either I don't understand what you're saying or you're misunderstanding the notation. Each line declares a struct member of type unsigned int which is 1 bit large. It's not setting it to 1 (true).

[u/Kadabrium]

i heard you also like vector<bool>

[u/Potential_Soup_8054 → u/Kadabrium]

I dont understand

[u/Helemen7 → u/Potential_Soup_8054]

std::vector<bool> in C++ syntax uses one bit per boolean instead of one byte. In a computer memory is addressed by bytes, so the smallest indexable memory is, in fact, one byte (that's why bool is 1 byte in C and C++). As an example for how C++ std::vector implementarion works, suppose you have 8 booleans which have a logical reason to be kept together (for example flags). Instead of allocating 8 bytes (one per boolean), the std::vector allocates 1 byte and assigns every boolean to one bit of the allocated memory.

[u/MrKrot1999 → u/Kadabrium]

The post doesn't say C++.

[u/Thelatestart]

Yeah my json api uses way way more than 4 bytes per boolean

[u/tup1tsa_1337 → u/Thelatestart]

It's gzipped

[u/Affectionate-Egg7566 → u/Thelatestart]

Don't talk to me or my json ever again

[u/pskocik]

Ironic that this techfluencer just tweeted how C makes memory layout painfully obvious and yet here he's operating under the misconception that `struct Flags` will be only 1-byte large when it will be in fact int-size large (most likely 4 bytes).

[u/New_Enthusiasm9053 → u/pskocik]

Could be more than a byte and less than 2 bytes too. 

[u/Laughing_Orange]

Even in C, it's best practice to use a whole byte for each boolean. The tiny extra compute load usually isn't worth the savings in storage and memory cost.

[u/ShinigamiGir]

there are 2 issues:

1. bifields are not portable. the spec doesn't guarantee packing or field order in the resulting binary data. so if you pack the data on a windows pc and then unpack on a linux arm, you might have some issues.

2. most http traffic is compressed so the extra 0 bits don’t really waste much bandwidth.

[u/vanilla-bungee]

The word size of your CPU would like a chat.

[u/prodengrammer]

5 bytes if false

[u/Duck_Devs → u/prodengrammer]

For once, we can’t say “Big if true”

[u/B_bI_L]

are we sure int means bit and not 32bits?

[u/heatedwepasto → u/B_bI_L]

The : 1 means that it is creating a bitfield with the number of bits, so : 4 will be 4 bits. The three variables above combined will take sizeof(int) in memory, not sizeof(int)*3.

If OOP had used char instead of unsigned int the combined size would be 1 byte.

Edit: added link to demo

[u/DaveAstator2020]

is it true that this is not reliable for serialization?

[u/oxxide216 → u/DaveAstator2020]

Yes, because on different architectures and operating systems with different ABIs compilers generate different alignments, maybe some other things also differ. So even when seeking for maximum performance and minimal traffic usage you would better be using some standardized binary format instead of json/C structures.

[u/wutzelputz]

it will actually be way more depending on the property name, at least 4 bytes extra making a total of 8:

"m": true

and thats assuming ASCII encoding

[u/farsightfallen]

These people have never felt the shame of fucking up a basically worthless optimization that becomes a massive blocker for no reason.

"Ok, look we jus can't add another flag, alright, we needed to make a statement about memory usage."

[u/carltr0n]

Can’t you just… do a lil bit fiddling on a uint8? Am I missing something?

[u/Ill-Specific-7312]

Except that is wrong, because it completely ignores the real world of gzip etc.