Почему разрешения enum часто имеют значения 0, 1, 2, 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
}

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

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

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

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);

Журнал 513 == 513

Так легче (для меня, по крайней мере) понять. Выстраивайте из них… опишите желаемый результат, получите желаемый результат. Никаких «расчетов» не требуется.