We Keep Coding

C# hexadecimal & comparison

I ran into a bit of code similar to the code below and was just curious if someone could help me understand what it's doing?:
int flag = 5;
Console.WriteLine(0x0E & flag);
// 5 returns 4, 6 returns 4, 7 returns 6, 8 returns 8
Sandbox:
https://dotnetfiddle.net/NnLyvJ

This is the bitwise AND operator.
It performs an AND operation on the bits of a number.
A logical AND operation on two [boolean] values returns True if the two values are True; False otherwise.
A bitwise AND operation on two numbers returns a number from all the bits of the two numbers that are 1 (True) in both numbers.
Example:
5 = 101
4 = 100
AND = 100 = 4
Therefore, 5 & 4 = 4.
This logic is heavily used for storing flags, you just need to assign each flag a power of 2 (1, 2, 4, 8, etc) so that each flag is stored in a different bit of the flags number, and then you just need to do flags & FLAG_VALUE and if the flag is set, it'll return FLAG_VALUE, otherwise 0.
C# provides a "cleaner" way to do this using enums and the Flags attribute.
[Flags]
public enum MyFlags
{
Flag0 = 1 << 0, // using the bitwise shift operator to make it more readable
Flag1 = 1 << 1,
Flag2 = 1 << 2,
Flag3 = 1 << 3,
}
void a()
{
var flags = MyFlags.Flag0 | MyFlags.Flag1 | MyFlags.Flag3;
Console.WriteLine(Convert.ToString((int) flags, 2)); // prints the binary representation of flags, that is "1011" (in base 10 it's 11)
Console.WriteLine(flags); // as the enum has the Flags attribute, it prints "Flag0, Flag1, Flag3" instead of treating it as an invalid value and printing "11"
Console.WriteLine(flags.HasFlag(MyFlags.Flag1)); // the Flags attribute also provides the HasFlag function, which is syntactic sugar for doing "(flags & MyFlags.Flag1) != 0"
}
Excuse my bad english.

Non binary Enum flags

In c# it is quite common to find the following Enum structure
[Flags]
public enum Permission
{
Read = 1 << 1,
Create = 1 << 2,
Update = 1 << 3,
Destroy = 1 << 4
}
which allows you to join enums like this: Permission.Read|Permission.Create
I am now faced with a different sort of requirement, and the solutions I have come up with are problematic IMO.
I need to allow some sort of enum implementation to multiple types of premissions - some contradicting, and some aren't
and I want the following sort of functionality
[Flags]
public enum Permission
{
Read1 = 1,
Read2 = 2,
Read3 = 3,
Write1 = 10,
Write2 = 20,
Write3 = 30,
Update1 = 100,
Update2 = 200,
Update3 = 300,
Destory = 1000,
Other = 10000,
SomethingElse = 100000,
}
when this won't work Permission.Read1|Permission.Read2 mainly because it means a user now has a reading permission level 3
besides using different bit flag for each Permission (which will require my db to hold a much larger integer than a INT for a very bad reason), or having a different enum (and column) per permission (which will limit my flexibility with the permissions) , and having no form of compile time verification (I guess I can create some sort of a workarroundish runtime verification) do you have any other idea?

Your db doesn't need to store bigger than int. 32bits can accommodate lot more values for unique bit flags. Following hex values are unique binary bit flags. Read1 | Read2 won't equal Read3
[Flags]
public enum Permission
{
Read1 = 0x00000001,
Read2 = 0x00000002,
Read3 = 0x00000004,
Write1 = 0x00000008,
Write2 = 0x00000010,
Write3 = 0x00000020,
Update1 = 0x00000040,
Update2 = 0x00000080,
Update3 = 0x00000100,
Destory = 0x00000400,
Other = 0x00000800,
SomethingElse = 0x00001000,
}
You can probably organize these better by blocking certain bit blocks as Read, Write etc. E.g. you can block Read to be blocked for first 8 bits, write for next 8 bits so on and so forth. That way, you can accommodate future changes and also use bit masking effectively.

Flags and << operation on enums? C# [duplicate]

This question already has answers here:
Why use the Bitwise-Shift operator for values in a C enum definition?
(9 answers)
Closed 6 years ago.
Ok so I am new to C#, and for the life of me I cannot comprehend what exactly the below code (from a legacy project) is supposed to do:
[Flags]
public enum EAccountStatus
{
None = 0,
FreeServiceApproved = 1 << 0,
GovernmentAccount = 1 << 1,
PrivateOrganisationAccount = 1 << 2,
All = 8
}
What exactly does the << operator do here on the enums? Why do we need this?

Behind the scenes, the enumeration is actually an int.
<< is the Bitwise Left Shift Operator
An equivalent way of writing this code is :
[Flags]
public enum EAccountStatus
{
None = 0,
FreeServiceApproved = 1,
GovernmentAccount = 2,
PrivateOrganisationAccount = 4,
All = 8
}
Please note, that this enumeration has the Flag attribute
As stated in the msdn:
Use the FlagsAttribute custom attribute for an enumeration only if a
bitwise operation (AND, OR, EXCLUSIVE OR) is to be performed on a
numeric value.
This way, if you want to have multiple options set you can use:
var combined = EAccountStatus.FreeServiceApproved | EAccountStatus.GovernmentAccount
which is equivalent to:
00000001 // =1 - FreeServiceApproved
| 00000010 // =2 - GovernmentAccount
---------
00000011 //= 3 - FreeServiceApproved and GovernmentAccount
this SO thread has a rather good explanation about the flags attribute

<< is doing simply what does i.e. Shift left operation.
As far as why in an enum is concerned, its just a way of evaluating the expression as enums allow expressions (and evaluate them on compile time)

How to combine enumerations with flags?

I have an enumeration with flags. I want to declare a variable with n different flags. n > 1 in this case.
public enum BiomeType {
Warm = 1,
Hot = 2,
Cold = 4,
Intermediate = 8,
Dry = 16,
Moist = 32,
Wet = 64,
}
Okay - one variant is to cast each flag into an byte and cast the result to my enum.
BiomeType bType = (BiomeType)((byte)BiomeType.Hot + (byte)BiomeType.Dry)
But this is kinda messy - imho. Is there an more readable way to combine flags?

Simple, use the binary "or" operator:
BiomeType bType = BiomeType.Hot | BiomeType.Dry;
Also, if the values can be combined like this it's best to mark the enum with the Flags attribute to indicate this:
[Flags]
public enum BiomeType {
Warm = 1,
Hot = 2,
Cold = 4,
Intermediate = 8,
Dry = 16,
Moist = 32,
Wet = 64,
}
Adding enumeration values is bad for a number of reasons. It makes it easy to produce a value that is outside the defined values, i.e.:
BiomeType bType = (BiomeType)((byte)BiomeType.Wet + (byte)BiomeType.Wet);
While contrived, this example yields a value of 128, which doesn't map to a known value. This will still compile and run, but it's likely you didn't build your code to handle values outside of those defined and could lead to undefined behavior. However, if you use the pipe (or "binary or") operator:
BiomeType bType = BiomeType.Wet | BiomeType.Wet;
The result is still just BiomeType.Wet.
Furthermore, using addition like in your question provides no Intellisense in the IDE which makes using the enumeration unnecessarily more difficult.

Add the [Flags] attribute to your enum. Then you can just mask them:
[Flags]
public enum BiomeType
{
Warm = 1,
Hot = 2,
Cold = 4,
Intermediate = 8,
Dry = 16,
Moist = 32,
Wet = 64,
}
BiomeType bType = BiomeType.Hot | BiomeType.Dry;
(Actually you can mask then without the flags attribute, but you should add it for clarity.)
You can even do something like this to combine all the flags:
var allBiomeTypes = ((BiomeType[])Enum.GetValues(typeof(BiomeType))).Aggregate((BiomeType)0, (a, c) => a | c);

Use the | (bitwise or) operator. You get IntelliSense support for this. (The other bitwise operators function the same as they do on the underlying numeric type.)
var bType = BiomeType.Hot | BiomeType.Dry;
You should also use the [Flags] attribute as a hint on the enum definition:
[Flags]
public enum BiomeType
{
Warm = 1,
Hot = 2,
Cold = 4,
Intermediate = 8,
Dry = 16,
Moist = 32,
Wet = 64,
}
(For an explanation, see What does the [Flags] Enum Attribute mean in C#?)

Why do enum permissions often have 0, 1, 2, 4 values?

Why are people always using enum values like 0, 1, 2, 4, 8 and not 0, 1, 2, 3, 4?
Has this something to do with bit operations, etc.?
I would really appreciate a small sample snippet on how this is used correctly :)
[Flags]
public enum Permissions
{
None = 0,
Read = 1,
Write = 2,
Delete = 4
}

Because they are powers of two and I can do this:
var permissions = Permissions.Read | Permissions.Write;
And perhaps later...
if( (permissions & Permissions.Write) == Permissions.Write )
{
// we have write access
}
It is a bit field, where each set bit corresponds to some permission (or whatever the enumerated value logically corresponds to). If these were defined as 1, 2, 3, ... you would not be able to use bitwise operators in this fashion and get meaningful results. To delve deeper...
Permissions.Read == 1 == 00000001
Permissions.Write == 2 == 00000010
Permissions.Delete == 4 == 00000100
Notice a pattern here? Now if we take my original example, i.e.,
var permissions = Permissions.Read | Permissions.Write;
Then...
permissions == 00000011
See? Both the Read and Write bits are set, and I can check that independently (Also notice that the Delete bit is not set and therefore this value does not convey permission to delete).
It allows one to store multiple flags in a single field of bits.

If it is still not clear from the other answers, think about it like this:
[Flags]
public enum Permissions
{
None = 0,
Read = 1,
Write = 2,
Delete = 4
}
is just a shorter way to write:
public enum Permissions
{
DeleteNoWriteNoReadNo = 0, // None
DeleteNoWriteNoReadYes = 1, // Read
DeleteNoWriteYesReadNo = 2, // Write
DeleteNoWriteYesReadYes = 3, // Read + Write
DeleteYesWriteNoReadNo = 4, // Delete
DeleteYesWriteNoReadYes = 5, // Read + Delete
DeleteYesWriteYesReadNo = 6, // Write + Delete
DeleteYesWriteYesReadYes = 7, // Read + Write + Delete
}
There are eight possibilities but you can represent them as combinations of only four members. If there were sixteen possibilities then you could represent them as combinations of only five members. If there were four billion possibilities then you could represent them as combinations of only 33 members! It is obviously far better to have only 33 members, each (except zero) a power of two, than to try to name four billion items in an enum.

Because these values represent unique bit locations in binary:
1 == binary 00000001
2 == binary 00000010
4 == binary 00000100
etc., so
1 | 2 == binary 00000011
EDIT:
3 == binary 00000011
3 in binary is represented by a value of 1 in both the ones place and the twos place. It is actually the same as the value 1 | 2. So when you are trying to use the binary places as flags to represent some state, 3 isn't usually meaningful (unless there is a logical value that actually is the combination of the two)
For further clarification, you might want to extend your example enum as follows:
[Flags]
public Enum Permissions
{
None = 0, // Binary 0000000
Read = 1, // Binary 0000001
Write = 2, // Binary 0000010
Delete = 4, // Binary 0000100
All = 7, // Binary 0000111
}
Therefore in I have Permissions.All, I also implicitly have Permissions.Read, Permissions.Write, and Permissions.Delete

[Flags]
public Enum Permissions
{
None = 0; //0000000
Read = 1; //0000001
Write = 1<<1; //0000010
Delete = 1<<2; //0000100
Blah1 = 1<<3; //0001000
Blah2 = 1<<4; //0010000
}
I think writing using a binary shift operator << is easier to understand and read, and you don't need to calculate it.

These are used to represent bit flags which allows combinations of enum values. I think it's clearer if you write the values in hex notation
[Flags]
public Enum Permissions
{
None = 0x00,
Read = 0x01,
Write = 0x02,
Delete= 0x04,
Blah1 = 0x08,
Blah2 = 0x10
}

This is really more of a comment, but since that wouldn't support formatting, I just wanted to include a method I've employed for setting up flag enumerations:
[Flags]
public enum FlagTest
{
None = 0,
Read = 1,
Write = Read * 2,
Delete = Write * 2,
ReadWrite = Read|Write
}
I find this approach especially helpful during development in the case where you like to maintain your flags in alphabetical order. If you determine you need to add a new flag value, you can just insert it alphabetically and the only value you have to change is the one it now precedes.
Note, however, that once a solution is published to any production system (especially if the enum is exposed without a tight coupling, such as over a web service), then it is highly advisable against changing any existing value within the enum.

Lot's of good answers to this one… I'll just say.. if you do not like, or cannot easily grasp what the << syntax is trying to express.. I personally prefer an alternative (and dare I say, straightforward enum declaration style)…
typedef NS_OPTIONS(NSUInteger, Align) {
AlignLeft = 00000001,
AlignRight = 00000010,
AlignTop = 00000100,
AlignBottom = 00001000,
AlignTopLeft = 00000101,
AlignTopRight = 00000110,
AlignBottomLeft = 00001001,
AlignBottomRight = 00001010
};
NSLog(#"%ld == %ld", AlignLeft | AlignBottom, AlignBottomLeft);
LOG 513 == 513
So much easier (for myself, at least) to comprehend. Line up the ones… describe the result you desire, get the result you WANT.. No "calculations" necessary.