is using an integer to store many bool worth the effort?

I was considering ways to reduce memory footprint, and it is constantly mentioned that a bool takes up more memory than it logically needs to, as a byproduct of processor design.
it is also sometimes mentioned that one could store several bool within an int.
I am wondering if this would actually be more memory efficient?

if we have a usecase where we can use a significant portion of 32 (or 64) bool. and we decide to store all of them in a single int. then on the surface we have saved

7 (bits) * 32 (size of int) = 224 (bits) or 28 (bytes)

but in order to get each of those bits from the int, we needed to use some method of masking
such as:

• bit shifting the int both directions (int<<x)>>y here we need to load and store x,y which are probably an int, but you could get them smaller depending on the use case
• masking the int: int & int2 here we also store an additional int, which is stored and loaded

even if these aren’t stored as variables, and they are defined statically within the code, it still ends up using additional memory, as it will increase the memory footprint of the instructions. as well as the instructions for the masking steps.

is there any way to do this that isn’t actually worse for memory usage than just taking the hit on 7 wasted bits?

>Solution :

You are describing a text book example of a trade-off.
Yes, several bools in one int is hugeley more memory efficient – in itself.
Yes, you need to spend code to use that.
Yes, for only a few bools (for different values of "few"), the code might take more space than you save.

However, you could look at the kind of memory which is used. In some environments, RAM (which is saved by your idea) is much more expensive than ROM (which has to be paid for your idea).
Also, the price to pay is mostly paid once for implementation and only paid a fraction for using, especially when the using code is reused, e.g. in loops.

Altogether, in case of many bools, you can save more than you pay.
The point of actually saving needs to be determined for the special case.

On the other hand, you have missed on "currency" on the price-tag for the idea. You not only pay in memory, you also pay in execution time. You focused your question on memory, so I won’t elaborate here. But for anything time critical, you should take the longer execution time into conisderation. You might find that saving memory is quite achievable with your idea, but the whole thing gets unbearably slow.