Perché le autorizzazioni enum hanno spesso valori 0, 1, 2, 4?

Perché le persone usano sempre i valori enum come 0, 1, 2, 4, 8e no 0, 1, 2, 3, 4?

Ha qualcosa a che fare con le operazioni sui bit, ecc.?

Gradirei davvero un piccolo frammento di esempio su come questo viene utilizzato correttamente :)

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

Perché sono poteri di due e posso farlo:

var permissions = Permissions.Read | Permissions.Write;

E forse più tardi ...

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

È un campo di bit, in cui ogni bit impostato corrisponde a qualche autorizzazione (oa qualunque valore logico corrispondente corrisponda logicamente). Se questi fossero definiti come non 1, 2, 3, ...si sarebbe in grado di utilizzare operatori bit per bit in questo modo e ottenere risultati significativi. Per approfondire ...

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

Notare uno schema qui? Ora se prendiamo il mio esempio originale, cioè

var permissions = Permissions.Read | Permissions.Write;

Poi...

permissions == 00000011

Vedere? Entrambi i bit Reade Writesono impostati e posso verificarlo in modo indipendente (Notare anche che il Deletebit non è impostato e quindi questo valore non trasmette l'autorizzazione per l'eliminazione).

Permette di memorizzare più flag in un singolo campo di bit.

Se non è ancora chiaro dalle altre risposte, pensaci in questo modo:

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

è solo un modo più breve per scrivere:

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
} 

Esistono otto possibilità, ma puoi rappresentarle come combinazioni di soli quattro membri. Se ci fossero sedici possibilità, potresti rappresentarle come combinazioni di soli cinque membri. Se ci fossero quattro miliardi di possibilità, potresti rappresentarle come combinazioni di soli 33 membri! È ovviamente molto meglio avere solo 33 membri, ciascuno (tranne zero) una potenza di due, piuttosto che cercare di nominare quattro miliardi di oggetti in un enum.

Poiché questi valori rappresentano posizioni di bit univoche in binario:

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

ecc

1 | 2 == binary 00000011

MODIFICARE:

3 == binary 00000011

3 in binario è rappresentato da un valore di 1 sia nella posizione uno che nella posizione due. In realtà è lo stesso del valore 1 | 2. Pertanto, quando si tenta di utilizzare i posti binari come flag per rappresentare un certo stato, 3 non è in genere significativo (a meno che non esista un valore logico che sia effettivamente la combinazione dei due)

Per ulteriori chiarimenti, potresti voler estendere il tuo esempio come segue:

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

Pertanto nel Ho Permissions.All, ho anche implicitamente avere Permissions.Read, Permissions.WriteePermissions.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
}

Penso che scrivere in questo modo sia più facile da capire e da leggere, e non è necessario calcolarlo.

Questi sono usati per rappresentare flag di bit che consentono combinazioni di valori enum. Penso che sia più chiaro se scrivi i valori in notazione esadecimale

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

Questo è davvero più di un commento, ma dal momento che non supporta la formattazione, volevo solo includere un metodo che ho usato per impostare le enumerazioni di flag:

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

Trovo questo approccio particolarmente utile durante lo sviluppo nel caso in cui ti piace mantenere le tue bandiere in ordine alfabetico. Se decidi che devi aggiungere un nuovo valore di bandiera, puoi semplicemente inserirlo in ordine alfabetico e l'unico valore che devi modificare è quello che ora precede.

Si noti, tuttavia, che una volta che una soluzione viene pubblicata su qualsiasi sistema di produzione (specialmente se l'enum viene esposto senza un accoppiamento stretto, ad esempio tramite un servizio Web), è consigliabile sconsigliare di modificare qualsiasi valore esistente all'interno dell'enum.

Molte buone risposte a questa ... dirò solo .. se non ti piace, o non riesci facilmente a capire ciò che la <<sintassi sta cercando di esprimere .. Personalmente preferisco un'alternativa (e oserei dire, semplice stile di dichiarazione 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);

LOG 513 == 513

Molto più facile (almeno per me) da capire. Allinea quelli ... descrivi il risultato che desideri, ottieni il risultato che VUOI. Non sono necessari "calcoli".