Почему разрешения enum часто имеют значения 0, 1, 2, 4?

Почему люди всегда используют значения перечисления как, 0, 1, 2, 4, 8а не как 0, 1, 2, 3, 4?

Это как-то связано с битовыми операциями и т. Д.?

Я был бы очень признателен за небольшой фрагмент кода о том, как это используется правильно :)

[Flags]
public enum Permissions
{
    None   = 0,
    Read   = 1,
    Write  = 2,
    Delete = 4
}

Потому что они являются полномочиями двух, и я могу сделать это:

var permissions = Permissions.Read | Permissions.Write;

И возможно позже ...

if( (permissions & Permissions.Write) == Permissions.Write )
{
    // we have write access
}

Это битовое поле, где каждый установленный бит соответствует определенному разрешению (или тому, что логически соответствует перечисляемому значению). Если бы они были определены как 1, 2, 3, ...вы не сможете использовать побитовые операторы таким образом и получить значимые результаты. Углубиться ...

Permissions.Read   == 1 == 00000001
Permissions.Write  == 2 == 00000010
Permissions.Delete == 4 == 00000100

Обратите внимание на шаблон здесь? Теперь, если мы возьмем мой оригинальный пример, т.е.

var permissions = Permissions.Read | Permissions.Write;

Затем...

permissions == 00000011

Видеть? Оба Readи Writeбиты установлены, и я могу проверить , что независимо друг от друга (Также обратите внимание , что Deleteбит не установлен , и поэтому это значение не передает разрешение на удаление).

Это позволяет хранить несколько флагов в одном поле битов.

Если это все еще не ясно из других ответов, подумайте об этом так:

[Flags] 
public enum Permissions 
{   
   None = 0,   
   Read = 1,     
   Write = 2,   
   Delete = 4 
} 

это просто более короткий способ написать:

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
} 

Есть восемь возможностей, но вы можете представлять их как комбинации только четырех участников. Если бы было шестнадцать вариантов, вы могли бы представлять их как комбинации только пяти участников. Если бы было четыре миллиарда возможностей, вы могли бы представлять их как комбинации только из 33 участников! Очевидно, что гораздо лучше иметь только 33 члена, каждый (кроме нуля) со степенью двойки, чем пытаться назвать четыре миллиарда предметов в перечислении.

Поскольку эти значения представляют уникальные местоположения битов в двоичном коде:

1 == binary 00000001
2 == binary 00000010
4 == binary 00000100

и т.д., так

1 | 2 == binary 00000011

РЕДАКТИРОВАТЬ:

3 == binary 00000011

3 в двоичном виде представлен значением 1 как в одном, так и в двойном разрядах. Это на самом деле так же, как значение 1 | 2. Поэтому, когда вы пытаетесь использовать двоичные места в качестве флагов для представления некоторого состояния, 3 обычно не имеет смысла (если нет логического значения, которое на самом деле является комбинацией двух)

Для дальнейшего пояснения вы можете расширить пример перечисления следующим образом:

[Flags]
public Enum Permissions
{
  None = 0,   // Binary 0000000
  Read = 1,   // Binary 0000001
  Write = 2,  // Binary 0000010
  Delete = 4, // Binary 0000100
  All = 7,    // Binary 0000111
}

Поэтому в меня Permissions.All, я также имею неявный Permissions.Read, Permissions.Writeи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
}

Я думаю, что писать, как это легче понять и прочитать, и вам не нужно рассчитывать это.

Они используются для представления битовых флагов, которые допускают комбинации значений перечисления. Я думаю, что будет понятнее, если вы напишите значения в шестнадцатеричной записи

[Flags]
public Enum Permissions
{
  None =  0x00,
  Read =  0x01,
  Write = 0x02,
  Delete= 0x04,
  Blah1 = 0x08,
  Blah2 = 0x10
}

Это действительно больше комментарий, но так как он не поддерживает форматирование, я просто хотел включить метод, который я использовал для настройки перечисления флагов:

[Flags]
public enum FlagTest
{
    None = 0,
    Read = 1,
    Write = Read * 2,
    Delete = Write * 2,
    ReadWrite = Read|Write
}

Я считаю, что этот подход особенно полезен во время разработки, если вы хотите поддерживать свои флаги в алфавитном порядке. Если вы решите, что вам нужно добавить новое значение флага, вы можете просто вставить его в алфавитном порядке, и единственное значение, которое вам нужно изменить, это то, которое ему предшествует.

Однако обратите внимание, что после публикации решения в любой производственной системе (особенно, если перечисление предоставляется без жесткой связи, например, через веб-службу), тогда настоятельно рекомендуется не изменять любое существующее значение в перечислении.

Множество хороших ответов на этот вопрос ... я просто скажу ... если вам не нравится, или вы не можете легко понять, что <<синтаксис пытается выразить .. Я лично предпочитаю альтернативу (и, смею сказать, простой стиль декларации перечисления) ...

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

Гораздо проще (по крайней мере, для себя) понять. Выстроите их в ряд ... опишите результат, который вы хотите, получите результат, который вы ХОТИТЕ. Никаких "вычислений" не требуется.