Requirements
This tutorial assumes a basic knowledge of C# and basic binary/logical operators.

Scenario

Quote

You're writing an application with multiple settings that require saving to disk or to memory, but there are potentially hundreds of flags that need to be tracked/saved; the settings file doesn't necessarily have to be human readable and you want to save memory wherever you can.

The madness of bool
In order to appease the previous scenario, assume you have the following class with several arbitrary settings that need to be saved:

This seems like a perfectly valid series of properties to hold our flags don't you think? Each boolean represents something in the program and can easily be used like so:

if(exampleInstance.usesFastBrowse)
{
// Code
}

But what you might not have considered, is how terribly inefficient this is. According to MSDN, a Boolean (or bool) is 8 bits in size, making our class above use 24 bits to store 3 flags.

Let me make that clear for you. 24 bits = 3 bytes. We are using 3 bytes to store 3 true/false pieces of information. This seems a tad excessive, considering the smallest value that can represent true/false is a single bit. Why is a bool a byte then? Not a clue. How does it work? what does it do with all those bits? well...

The example above shows us how truly mad booleans are in C#, they use 255/256 possible combinations to mean the same thing when it could be eloquently summed up using a single bit and a trivial function to convert integer to bool.

1 = true
0 = false
Boolean intToBool(int i)
{
return (i > 0);
}

So how can I break free of this madness when C# only offers datatypes of 8 bits or more? Oddly enough, you can look at another Microsoft work to determine a brilliant answer: the Windows API (or WinApi).

The WinApi
While I was playing around with the WinApi, I saw that a lot of settings were set using a similar pattern:

The above sample seemed brilliant! Just set the transition type and away it went. But what did those numbers actually mean? And what if I wanted to mix animations? Turns out it's VERY simple:

AnimateWindow(windowToAnimate.Handle, // Window we want to animate
2000, // How long the animation should take
TransitionType.CENTER | TransitionType.ACTIVATE); // Animate using a 'zoom' style effect to make the window appear

There we go, we just told it to use the zoom function to show the window. What if we wanted to hide it? Just replace ACTIVATE with HIDE and we're good to go. Now this seems great, but what I still haven't said is what those numbers mean and how this relates to booleans! I didn't even say what that bar thing is! Well that's coming right up in...

Using OR to fix the madness
In the last example you saw me use the vertical bar (or pipe) to mix two settings, this is called the OR operator and its function is exactly the same as in electronics. It iterates through each bit in the two values and if one of them is a 1, the result is 1, otherwise, it's a 0 e.g.

0001
0011
-----
0011

Now in order to demonstrate how it applies to the enum we will use our original example only modified somwhat:

Now we have completely done away with our booleans and replaced them with a singular byte. But we've also created an enum to hold a list of the possible flags we need to monitor. But WHY ARE THEY NUMBERED LIKE THAT!?!? It's simple really! Remember how we said we only really need 1 bit to determine if something is true or false? Well that means to show three flags we only need 3 bits!

//USE HD VALIDATE FAST_BROWSE
0 0 0

By changing the '0's to '1's we can turn different features on or off and if we take away the headings we are left with:

So that's how we give them their special numbers. We give them the integer representation of their on state in binary. Why would we do this? So we can manipulate our settings number with ease. Because C# doesn't let us use less than 1 byte our settings string is 8 empty bits structured like so:

// Unused USE HD VALIDATE FAST_BROWSE
0000 0 0 0 0

Okay, so we can in theory represent 8 different flags in this one byte. That's 1/8th of the memory of using 8 booleans. Cool right? But don't PC's have a LOT of memory anyway? Well, yes. But what if you were performing millions of writes per second? or sending a lot of data across a network? A small size is a big benefit in these situations.

So now we're clear on WHY it's a good idea, how would you go about changing the individual bits? It's not like you can index into an int like an array. Fortunately here is where OR comes in. Let me show you an example

Notice how the result matches what we're trying to match? If it doesn't it will return 0 instead, this means we can use it in if statements like so:

// Usage:
if(VALIDATE == (settings & VALIDATE))
{
// Code
}

Now you may this this is rather silly, look at all that extra work for a bit of saved memory. This is where I concede, you shouldn't be using this all the time. It hurts code readability, sure you can encapsulate this logic in a function, but it's more long winded. If you're not trying to save memory/space then you should just use the standard boolean values. Yes, it takes up more room, but isn't