Чому переліки прапорців зазвичай визначаються шістнадцятковими значеннями

Багато разів я бачу декларації перерахувань прапорців, які використовують шістнадцяткові значення. Наприклад:

[Flags]
public enum MyEnum
{
    None  = 0x0,
    Flag1 = 0x1,
    Flag2 = 0x2,
    Flag3 = 0x4,
    Flag4 = 0x8,
    Flag5 = 0x10
}

Коли я оголошую перерахунок, я зазвичай декларую це так:

[Flags]
public enum MyEnum
{
    None  = 0,
    Flag1 = 1,
    Flag2 = 2,
    Flag3 = 4,
    Flag4 = 8,
    Flag5 = 16
}

Чи є причина чи обґрунтування того, чому деякі люди вибирають записати значення у шістнадцятковій, а не в десятковій формі? Те, як я це бачу, простіше заплутатися під час використання шістнадцяткових значень і випадково писати Flag5 = 0x16замість Flag5 = 0x10.

Обгрунтування може відрізнятися, але перевага, яку я бачу, полягає в тому, що шістнадцятковий нагадує вам: "Гаразд, ми вже не маємо справу з числами у довільному світі, придуманому людиною, базовим десятьм. Ми маємо справу з бітами - світовим апаратом - і ми грати за його правилами. " Шістнадцятковий використовується дуже рідко, якщо ви не маєте питань щодо відносно низьких рівнів, де важливе розташування даних пам'яті. Використання цього натякає на той факт, що зараз у цій ситуації.

Крім того, я не впевнений у C #, але я знаю, що в C x << y- дійсна константа часу компіляції. Використання бітових зрушень здається найбільш зрозумілим:

[Flags]
public enum MyEnum
{
    None  = 0,
    Flag1 = 1 << 0,
    Flag2 = 1 << 1,
    Flag3 = 1 << 2,
    Flag4 = 1 << 3,
    Flag5 = 1 << 4
}

Це дозволяє легко побачити, що це бінарні прапори.

None  = 0x0,  // == 00000
Flag1 = 0x1,  // == 00001
Flag2 = 0x2,  // == 00010
Flag3 = 0x4,  // == 00100
Flag4 = 0x8,  // == 01000
Flag5 = 0x10  // == 10000

Хоча прогрес робить його ще чіткішим:

Flag6 = 0x20  // == 00100000
Flag7 = 0x40  // == 01000000
Flag8 = 0x80  // == 10000000

Я думаю, що це просто тому, що послідовність завжди 1,2,4,8, а потім додаємо 0.
Як ви бачите:

0x1 = 1 
0x2 = 2
0x4 = 4
0x8 = 8
0x10 = 16
0x20 = 32
0x40 = 64
0x80 = 128
0x100 = 256
0x200 = 512
0x400 = 1024
0x800 = 2048

і так далі, доки ви пам'ятаєте послідовність 1-2-4-8, ви можете створити всі наступні прапори, не пам'ятаючи про сили 2

Тому що [Flags]означає, що перерахунок - це справді бітове поле . З [Flags]ви можете використовувати побітовое І ( &) і OR ( |) оператори , щоб об'єднати прапори. У роботі з подібними двійковими значеннями майже завжди зрозуміліше використовувати шістнадцяткові значення. Це саме причина, в якій ми в першу чергу використовуємо шістнадцятковий . Кожному шістнадцятковому символу відповідає рівно одна шпилька (чотири біти). З десятковою ознакою це відображення від 1 до 4 не відповідає дійсності.

Оскільки існує механічний, простий спосіб подвоїти потужність двох у шестигранному. У десятковій частині це важко. Це вимагає тривалого розмноження у вашій голові. У hex це проста зміна. Ви можете виконувати це так, як 1UL << 63ви не можете робити десятковим способом .

Тому що людям легше прослідкувати там, де шматочки знаходяться у прапорі. Кожна шістнадцяткова цифра може вміщувати 4-бітний двійковий код.

0x0 = 0000
0x1 = 0001
0x2 = 0010
0x3 = 0011

... and so on

0xF = 1111

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

Отже, якщо вам потрібні прапори з 16 бітами, ви будете використовувати чотиризначні шістнадцяткові значення, і таким чином ви зможете уникнути помилкових значень:

0x0001 //= 1 = 000000000000 0001
0x0002 //= 2 = 000000000000 0010
0x0004 //= 4 = 000000000000 0100
0x0008 //= 8 = 000000000000 1000
...
0x0010 //= 16 = 0000 0000 0001 0000
0x0020 //= 32 = 0000 0000 0010 0000
...
0x8000 //= 32768 = 1000 0000 0000 0000