Tell me the truth ...

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;
- 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 booleans
  
  That's only for C++, as far as I can tell that struct is valid C
- 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 } }
  
  Why not if (f & (F_1 | F_3)) {? I use this all the time in embedded code.
  edit: never mind; you’re checking for both flags. I’d probably use (f & (F_1 | F_3)) == (F_1 | F_3) but that’s not much different than what you wrote.

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.
  
  Fucking lol at the downvoters haha that second sentence must have rubbed them the wrong way for being too accurate.
  
  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?

I set all 8 bits to 1 because I want it to be really true.
- 01111111 = true
  11111111 = negative true = false
  
  00001111 = maybe
  
  What if it's an unsigned boolean?
  
  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 .
  
  Why do alternative facts always gotta show up uninvited to the party? 🥳
  
  So all this time true was actually false and false was actually true ?
  
  negative true = negative non-zero = non-zero = true.
- 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.
- 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
- 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.

string boolEnable = "True";
- Violence
  
  Maybe json is named after Jason Voorhees

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
- A lot of times using less memory is actually better for performance because the main bottleneck is memory bandwidth or latency.
  
  Yep, and anding with a bit ask is incredibly fast to process, so it's not a big issue for performance.
  
  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.
- And you may ask yourself: where is my beautiful house? Where is my beautiful wife?
  
  Soon to be
  That's me
  
  Letting the days go by, let the water hold me down

Wait till you find out about alignment and padding
- Tell me the truth, i can handle it

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)
- 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.
- 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.
  
  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 😅
  
  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.)
  
  Which part?
- Edit - oops, responded to wrong comment...

In the industrial automation world and most of the IT industry, data is aligned to the nearest word. Depending on architecture, that's usually either 16, 32, or 64 bits. And that's the space a single Boolean takes.
- That's why I primarily use booleans in return parameters, beyond that I'll try to use bitfields. My game engine's tilemap format uses a 32 bit struct, with 16 bit selecting the tile, 12 bit selecting the palette, and 4 bit used for various bitflags (horizontal and vertical mirroring, X-Y axis invert, and priority bit).
  
  Bit fields are a necessity in low level networking too.
  They're incredibly useful, I wish more people made use of them.
  I remember I interned at a startup programming microcontrollers once and created a few bitfields to deal with something. Then the lead engineer went ahead and changed them to masked ints. Because. The most aggravating thing is that an int size isn't consistent across platforms, so if they were ever to change platforms to a different word length, they'd be fucked as their code was full of platform specific shenanigans like that.
  /rant

The 8-bit Intel 8051 family provides a dedicated bit-addressable memory space (addresses 20h-2Fh in internal RAM), giving 128 directly addressable bits. Used them for years. I'd imagine many microcontrollers have bit-width variables.
bit myFlag = 0;
Or even return from a function:
bit isValidInput(unsigned char input) { // Returns true (1) if input is valid, false (0) otherwise return (input >= '0' && input <= '9'); }
- Nothing like that in ARM. Even microcontrollers have enough RAM that nobody cares, I guess.
  
  ARM has bit-banding specifically for this. I think it’s limited to M-profile CPUs (e.g. v7-M) but I’ve definitely used this before. It basically creates a 4-byte virtual address for every bit in a region. So the CPU itself can’t “address” a bit but it can access an address backed by only 1 bit of SRAM or registers (this is also useful to atomically access certain bits in registers without needing to use SW atomics).
  
  Tell this to the LPC1114 I'm working with. Did you ever run a multilingual GUI from 2kbytes RAM on a 256x32 pixel display?
- We could go the other way as well: TI's C2000 microcontroller architecture has no way to access a single byte, let alone a bit. A Boolean is stored in 16-bits on that one.
- And, you can have pointers to bits!

Peasant...
https://github.com/aumuell/open-inventor/blob/014e2bf17f50f5d510cdd57744d03c436ee9ce27/lib/database/include/Inventor/SbBasic.h#L83
- Weird how I usually learn more from the humor communities than the serious ones... 😎

std::vector<bool> fits eight booleans into one byte.
- std::vector<std::vector
  <bool>
  > is how I stored the representation of a play field for a Tetris game I made once.
- cpp
  
  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.

It's far more often stored in a word, so 32-64 bytes, depending on the target architecture. At least in most languages.
- No it isn't. All statically typed languages I know of use a byte. Which languages store it in an entire 32 bits? That would be unnecessarily wasteful.
  
  C, C++, C#, to name the main ones. And quite a lot of languages are compiled similarly to these.
  To be clear, there's a lot of caveats to the statement, and it depends on architecture as well, but at the end of the day, it's rare for a byte or bool to be mapped directly to a single byte in memory.
  Say, for example, you have this function...
  cs
  
  public void Foo() { bool someFlag = false; int counter = 0; ... }
  The someFlag and counter variables are getting allocated on the stack, and (depending on architecture) that probably means each one is aligned to a 32-bit or 64-bit word boundary, since many CPUs require that for whole-word load and store instructions, or only support a stack pointer that increments in whole words. If the function were to have multiple byte or bool variables allocated, it might be able to pack them together, if the CPU supports single-byte load and store instructions, but the next int variable that follows might still need some padding space in front of it, so that it aligns on a word boundary.
  A very similar concept applies to most struct and object implementations. A single byte or bool field within a struct or object will likely result in a whole word being allocated, so that other variables and be word-aligned, or so that the whole object meets some optimal word-aligned size. But if you have multiple less-than-a-word fields, they can be packed together. C# does this, for sure, and has some mechanisms by which you can customize field packing.
  
  It's not wasteful, it's faster. You can't read one byte, you can only read one word. Every decent compiler will turn booleans into words.

if wasting a byte or seven matters to you, then then you need to be working in a lower level language.
- It's 7 bits....
  Pay attention. 🤪
  
  7 bytes! Look at Mr. Moneybags here!

I have a solution with a bit fields. Now your bool is 1 byte :
cpp

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:
cpp

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.

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

boolean bloat
- I first thought you wrote boolean float, not sure if that's even worse.
  
  boolean root beer float

True.
- Well storing that would only take half a bit.

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.

Wait until you hear about alignment
- The alignment of the language and the alignment of the coder must be similar on at least one metric, or the coder suffers a penalty to develop for each degree of difference from the language's alignment. This is penalty stacks for each phase of the project.
  So, let's say that the developer is a lawful good Rust ~~zealot~~ Paladin, but she's developing in Python, a language she's moderately familiar with. Since Python is neutral/good, she suffers a -1 penalty for the first phase, -2 for the second, -3 for the third, etc. This is because Rust (the Paladin's native language) is lawful, and Python is neutral (one degree of difference from lawful), so she operates at a slight disadvantage. However, they are both "good", so there's no further penalty.
  The same penalty would occur if using C, which is lawful neutral - but the axis of order and chaos matches, and there is one degree of difference on the axis of good and evil.
  However, if that same developer were to code in Javascript (chaotic neutral), it would be at a -3 (-6, -9...) disadvantage, due to 2 and 1 degree of difference in alignment, respectively.
  Malbolge (chaotic evil), however, would be a -4 (-8, -12) plus an inherent -2 for poor toolchain availability.
  ..hope this helps. have fun out there!

Are you telling me that no compiler optimizes this? Why?
- It would be slower to read the value if you had to also do bitwise operations to get the value.
  But you can also define your own bitfield types to store booleans packed together if you really need to. I would much rather that than have the compiler do it automatically for me.
- Well there are containers that store booleans in single bits (e.g. std::vector<bool> - which was famously a big mistake).
  But in the general case you don't want that because it would be slower.
  
  Why is this a big mistake? I’m not a c++ person
- Consider what the disassembly would look like. There's no fast way to do it.
  It's also unnecessary since 8 bytes is a negligible amount in most cases. Serialization is the only real scenario where it matters. (Edit: and embedded)
  
  In embedded, if you are to the point that you need to optimize the bools to reduce the footprint, you fucked up sizing your mcu.
- CPUs don't read one bit a a time.
- They do, that's the optimisation.

This reminds me that I actually once made a class to store bools packed in uint8 array to save bytes.
Had forgotten that. I think i have to update the list of top 10 dumbest things i ever did.

Wait till you here about every ascii letter. . .
- what about them?
  
  ASCII was originally a 7-bit standard. If you type in ASCII on an 8-bit system, every leading bit is always 0.
  (Edited to specify context)
  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.

We need to be able to express 0 and 1 as integers so that functionality is just being overloaded to express another concept.
Wait until the person who made this meme finds out about how many bits are being wasted on modern CPU architectures. 7 is the minimum possible wasted bits but it would be 31 on every modern computer (even 64b machines since they default to 32b ints).

Wait till you realise the size of SSD sectors

3GPP has an interesting way of serialising bools on the wire with ASN.1
NULL OPTIONAL
meaning only the type would be stored if true, otherwise it won't be set at all
- That requires some form of self describing format and will probably look like a sparse matrix in the end.

I swore I read that mysql dbs will store multiple bools in a row as bit maps in one byte. I can't prove it though
- I recall that sql server will group bit columns into bytes for storage, wouldn't surprise me if other flavours did something similar.
- SIMD Might be the term youre looking for (Single Input Multiple Data)

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.

7 Shades of Truth

...or you can be coding assembler - it's all just bits to me

pragma(pack) {
int a:1, b:1, ... h:1;
}
IIRC.

I mean is it really a waste? What's minimum amount of bits most CPUs read in one cycle.
- In terms of memory usage it's a waste. But in terms of performance you're absolutely correct. It's generally far more efficient to check is a word is 0 than to check if a single bit is zero.
- Usually the most effective way is to read and write the same amount of bits as the architecture of the CPU, so for 64 bit CPUs it's 64 bits at once.

Redundancy is nice in the event of bitflip errors
- Is the redundancy used for bools? I mean in actual practice.
  
  iunno ¯(ツ)_/¯
  
  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.

Could a kind soul ELI5 this? Well, maybe ELI8. I did quite a bit of programming in the 90-00s as part of my job, although nowadays I'm more of a script kiddie.
- A Boolean is a true/false value. It can only be those two values and there be represented by a single bit (1 or 0).
  In most languages a Boolean variable occupies the space of a full byte (8 bit) even though only a single of those bits is needed for representing the Boolean.
  That's mostly because computers can't load a bit. They can only load bytes. Your memory is a single space where each byte has a numeric address. Starting from 0 and going to whatever amount of memory you have available. This is not really true because on most operating systems each process gets a virtual memory space but its true for many microcontrollers. You can load and address each f these bytes but it will always be a byte. That's why booleans are stored as bytes because youd have to pack them with other data on the same address other wise and that's getting complicated.
  Talking about getting complicated, in C++ a std::vector
  <bool>
  is specialized as a bit field. Each of the values in that vector only occupy a single bit and you can get a vector of size 8 in a single byte. This becomes problematic when you want to store references or pointers to one of the elements or when you're working with them in a loop because the elements are not of type bool but some bool-reference type.
  
  And performance optimisation of a compiler for a 64 bit CPU will realign everything and each boolean will occupy 8 bytes instead.
- A boolean value only needs 1 bit (on or off) for true or false. However the smallest bit of addressable memory is a byte (8 bits) hence 7 are technically wasted.
  For low memory devices you could instead store 8 different Boolean values in one single byte by using bit masking instead

Pl/1 did it right:
Dcl 1 mybools, 3 bool1 bit(1) unaligned, 3 bool2 bit(1) unaligned, … 3 bool8 bit(1) unaligned;
All eight bools are in the same byte.

Does anybody ever figure in parity when comparing bit sizes and all that jazz or are we only ever concerned with storage space?
- You can't store data in parity bits... so it's irrelevant.

Now store the numbers (array):
0 0 0 1 0 1 1 2
think 8 bytes???