Перевага переключення на оператор if-else

Яка найкраща практика використання switch оператора проти використання ifоператора для 30 unsignedперерахувань, де приблизно 10 мають очікувані дії (на даний момент це та сама дія). Продуктивність та простір потрібно враховувати, але вони не є критичними. Я абстрагував фрагмент, тому не ненавиджу мене за умовами іменування.

switch заява:

// numError is an error enumeration type, with 0 being the non-error case
// fire_special_event() is a stub method for the shared processing

switch (numError)
{  
  case ERROR_01 :  // intentional fall-through
  case ERROR_07 :  // intentional fall-through
  case ERROR_0A :  // intentional fall-through
  case ERROR_10 :  // intentional fall-through
  case ERROR_15 :  // intentional fall-through
  case ERROR_16 :  // intentional fall-through
  case ERROR_20 :
  {
     fire_special_event();
  }
  break;

  default:
  {
    // error codes that require no additional action
  }
  break;       
}

if заява:

if ((ERROR_01 == numError)  ||
    (ERROR_07 == numError)  ||
    (ERROR_0A == numError)  || 
    (ERROR_10 == numError)  ||
    (ERROR_15 == numError)  ||
    (ERROR_16 == numError)  ||
    (ERROR_20 == numError))
{
  fire_special_event();
}

Використовуйте перемикач.

У гіршому випадку компілятор генерує той самий код, що і ланцюг if-else, тому ви нічого не втрачаєте. Якщо ви сумніваєтеся, поставте найчастіші випадки спочатку в оператор переключення.

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

Для особливого випадку, який ви вказали у своєму прикладі, мабуть, найясніший код:

if (RequiresSpecialEvent(numError))
    fire_special_event();

Очевидно, це просто переміщує проблему в іншу область коду, але тепер у вас є можливість повторно використовувати цей тест. Ви також маєте більше варіантів, як це вирішити. Ви можете використовувати std :: set, наприклад:

bool RequiresSpecialEvent(int numError)
{
    return specialSet.find(numError) != specialSet.end();
}

Я не припускаю, що це найкраща реалізація RequiresSpecialEvent, тільки що це варіант. Ви все ще можете використовувати комутатор або ланцюжок if-else, або таблицю пошуку, або якусь біт-маніпуляцію зі значенням, будь-яке. Чим незрозумілішим стає ваш процес прийняття рішень, тим більше значення ви отримаєте від того, щоб мати його в ізольованій функції.

Вимикач є швидше.

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

Тепер у перемикача є одна реальна проблема : комутатор повинен знати під час компіляції значення всередині кожного випадку. Це означає, що наступний код:

// WON'T COMPILE
extern const int MY_VALUE ;

void doSomething(const int p_iValue)
{
    switch(p_iValue)
    {
       case MY_VALUE : /* do something */ ; break ;
       default : /* do something else */ ; break ;
    }
}

не компілюється

Більшість людей тоді використовуватиме визначення (Aargh!), А інші оголошуватимуть та визначатимуть постійні змінні в одній і тій же одиниці компіляції. Наприклад:

// WILL COMPILE
const int MY_VALUE = 25 ;

void doSomething(const int p_iValue)
{
    switch(p_iValue)
    {
       case MY_VALUE : /* do something */ ; break ;
       default : /* do something else */ ; break ;
    }
}

Отже, врешті-решт, розробник повинен вибрати між "швидкістю + чіткістю" та "зчепленням коду".

(Не те, що перемикач не може бути записаний як заплутаний як пекло ... Більшість перемикачів, які я зараз бачу, є з цієї "заплутаної" категорії "... Але це вже інша історія ...)

Редагувати 2008-09-21:

bk1e додав наступний коментар: " Визначення констант як перерахунків у файлі заголовка - це ще один спосіб впоратися з цим".

Звичайно, так і є.

Суть зовнішнього типу полягала в тому, щоб відокремити значення від джерела. Визначення цього значення як макросу, як простого оголошення const int, або навіть як enum має побічний ефект від включення цього значення. Таким чином, якщо дефініція, значення enum чи значення const int зміниться, знадобиться перекомпіляція. Зовнішня декларація означає, що немає необхідності перекомпілювати у разі зміни значення, але, з іншого боку, унеможливлює використання перемикача. Висновок із використання перемикача збільшить зв'язок між кодом комутатора та змінними, що використовуються як випадки . Коли це нормально, тоді використовуйте перемикач. Коли це не так, то не дивно.

.

Редагувати 2013-01-15:

Влад Лазаренко прокоментував мою відповідь, давши посилання на своє поглиблене вивчення коду складання, що генерується комутатором. Дуже радісно: http://lazarenko.me/switch/

Компілятор все одно оптимізує його - перейдіть до перемикача, оскільки він найбільш читабельний.

Перемикач, якщо тільки для читабельності. Гігантські, якщо твердження важче підтримувати і важче читати на мій погляд.

ERROR_01 : // навмисне пропускання

або

(ERROR_01 == numError) ||

Пізніше більш схильна до помилок і вимагає більше введення та форматування, ніж перша.

Код для читабельності. Якщо ви хочете знати, що краще, скористайтеся профілером, оскільки оптимізації та компілятори різняться, а продуктивність рідко там, де люди думають, що вони є.

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

Я хотів би поставити надмірні ярлики на корпусі - просто для того, щоб людям було комфортно, я намагався згадати, коли / які правила є для їх виходу.
Ви не хочете, щоб черговий програміст, який працював над цим, не мав зайвих роздумів про мовні деталі (це може бути ви через кілька місяців!)

Компілятори справді хороші в оптимізації switch. Останні gcc також добре оптимізують купу умов уif .

Я зробив кілька тестових випадків на Godbolt .

Коли case значення згруповані близько один до одного, gcc, clang та icc все досить розумні, щоб використовувати растрову карту, щоб перевірити, чи є значення одним із спеціальних.

наприклад, gcc 5.2 -O3 збирає switchдо (і ifщось дуже схоже):

errhandler_switch(errtype):  # gcc 5.2 -O3
    cmpl    $32, %edi
    ja  .L5
    movabsq $4301325442, %rax   # highest set bit is bit 32 (the 33rd bit)
    btq %rdi, %rax
    jc  .L10
.L5:
    rep ret
.L10:
    jmp fire_special_event()

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

gcc 4.9.2 -O3 компілює switchв растрову карту, але робить 1U<<errNumberз mov / shift. Він компілює ifверсію до серії галузей.

errhandler_switch(errtype):  # gcc 4.9.2 -O3
    leal    -1(%rdi), %ecx
    cmpl    $31, %ecx    # cmpl $32, %edi  wouldn't have to wait an extra cycle for lea's output.
              # However, register read ports are limited on pre-SnB Intel
    ja  .L5
    movl    $1, %eax
    salq    %cl, %rax   # with -march=haswell, it will use BMI's shlx to avoid moving the shift count into ecx
    testl   $2150662721, %eax
    jne .L10
.L5:
    rep ret
.L10:
    jmp fire_special_event()

Зверніть увагу, як він віднімає 1 з errNumber(з leaкомбінувати цю операцію з переміщенням). Це дозволяє йому вписати растрове зображення в 32-бітовий негайний, уникаючи 64-бітового негайногоmovabsq який займає більше байтів інструкцій.

Коротка (в машинному коді) послідовність буде:

    cmpl    $32, %edi
    ja  .L5
    mov     $2150662721, %eax
    dec     %edi   # movabsq and btq is fewer instructions / fewer Intel uops, but this saves several bytes
    bt     %edi, %eax
    jc  fire_special_event
.L5:
    ret

(Невміння використовувати jc fire_special_eventвсюди, і це помилка компілятора .)

rep retвикористовується для галузевих цілей та наступних умовних гілок на користь старих AMD K8 та K10 ( передбульдозер ): Що означає `re ret`? . Без цього прогнозування галузей не працює на цих застарілих процесорах.

bt(бітовий тест) з аргументом регістру швидко. Він поєднує в собі роботу лівого зсуву a 1 на errNumberбіти і виконання atest , але все ж затримка 1 циклу і лише одна Intel взагалі. Із аргументом пам’яті це повільно через його семантику, яка занадто є CISC: з операндом пам’яті для «бітового рядка» адреса байта, що підлягає тестуванню, обчислюється на основі іншого аргументу (розділеного на 8), і isn не обмежується 1, 2, 4 або 8-байтним фрагментом, на який вказує операнд пам'яті.

З таблиць інструкцій Agner Fog інструкція зсуву змінної повільніше відбувається, ніж у btнедавнього Intel (2 Uops замість 1, і shift не робить все, що потрібно).

Переваги перемикача () over, якщо інший випадок:

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

3. Значення в комутаторі визначаються користувачем, тоді як значення в іншому випадку базуються на обмеженнях.

4. У випадку помилки, висловлювання в перемикачі можна легко перехрестити і виправити, що порівняно складно перевірити у випадку, якщо інше твердження.

5. Корпус комутатора набагато компактніший і легкий для читання та розуміння.

IMO - це прекрасний приклад того, для чого було зроблено пропуск комутатора.

Якщо ваші випадки, ймовірно, залишатимуться в групі в майбутньому - якщо одному результату відповідає більше ніж один випадок - комутатор може виявитися легшим для читання та обслуговування.

Вони однаково добре працюють. Продуктивність приблизно така ж, як і сучасний компілятор.

Я вважаю за краще, якщо висловлювання над твердженнями випадків, оскільки вони є більш читабельними та більш гнучкими - ви можете додати інші умови, не засновані на числовій рівності, наприклад "|| max <min". Але для простого випадку, який ви розмістили тут, це насправді не має значення, просто робіть те, що вам найчитає.

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

Дублювання в ifстані важко для очей. Припустимо, ==був написаний один із!= ; ти помітив би? Або якщо в одному екземплярі "numError" було написано "nmuError", який щойно трапився для компіляції?

Я взагалі вважаю за краще використовувати поліморфізм замість перемикача, але без деталей контексту важко сказати.

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

Я погоджуюся з сумісністю рішення комутатора, але ІМО ви тут викрадаєте вимикач .
Призначення вимикача полягає в різному керуванні залежно від значення.
Якби вам довелося пояснювати свій algo в псевдо-коді, ви б використовували if, тому що, семантично, це те, що це таке: якщо what_error зробити це ...
Тож якщо ви не збираєтесь колись змінити свій код, щоб мати специфічний код для кожної помилки , Я б користувався, якби .

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

Я б сказав, використовуйте SWITCH. Таким чином, вам доведеться реалізувати лише різні результати. Ваші десять однакових випадків можуть використовувати за замовчуванням. Якщо потрібно змінити все, що вам потрібно, явно реалізувати ці зміни, не потрібно редагувати типово. Додавати або видаляти випадки з SWITCH також набагато простіше, ніж редагувати IF та ELSEIF.

switch(numerror){
    ERROR_20 : { fire_special_event(); } break;
    default : { null; } break;
}

Можливо, навіть перевірити свій стан (в даному випадку числовий помилок) на перелік можливостей, можливо, масив, тому ваш SWITCH навіть не використовується, якщо напевно не буде результату.

Бачачи, що у вас є лише 30 кодів помилок, кодуйте власну таблицю стрибків, тоді ви робите всі варіанти оптимізації (стрибок завжди буде найшвидшим), а не сподіваєтесь, що компілятор зробить правильно. Це також робить код дуже малим (крім статичної декларації таблиці стрибків). Це також має побічну перевагу, що за допомогою налагоджувача ви можете змінювати поведінку під час виконання, якщо вам це потрібно, просто натискаючи на дані таблиці.

Я не впевнений у передовій практиці, але я б скористався перемикачем - а потім уловлював навмисне пропуск через "за замовчуванням"

Естетично я схильний до такого підходу.

unsigned int special_events[] = {
    ERROR_01,
    ERROR_07,
    ERROR_0A,
    ERROR_10,
    ERROR_15,
    ERROR_16,
    ERROR_20
 };
 int special_events_length = sizeof (special_events) / sizeof (unsigned int);

 void process_event(unsigned int numError) {
     for (int i = 0; i < special_events_length; i++) {
         if (numError == special_events[i]) {
             fire_special_event();
             break;
          }
     }
  }

Зробіть дані трохи розумнішими, щоб ми могли зробити логіку трохи тупішою.

Я розумію, це виглядає дивно. Ось натхнення (з того, як я це зробив би в Python):

special_events = [
    ERROR_01,
    ERROR_07,
    ERROR_0A,
    ERROR_10,
    ERROR_15,
    ERROR_16,
    ERROR_20,
    ]
def process_event(numError):
    if numError in special_events:
         fire_special_event()

while (true) != while (loop)

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

Що стосується складання програми, я не знаю, чи є якась різниця. Але що стосується самої програми та збереження коду максимально просто, я особисто думаю, що це залежить від того, що ви хочете зробити. якщо інше, якщо в інших заявах є свої переваги, які, на мою думку, є:

дозволяють перевірити змінну на конкретні діапазони, ви можете використовувати функції (Стандартна бібліотека або Особисті) як умовні.

(приклад:

`int a;
 cout<<"enter value:\n";
 cin>>a;

 if( a > 0 && a < 5)
   {
     cout<<"a is between 0, 5\n";

   }else if(a > 5 && a < 10)

     cout<<"a is between 5,10\n";

   }else{

       "a is not an integer, or is not in range 0,10\n";

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

`int a;
 cout<<"enter value:\n";
 cin>>a;

 switch(a)
 {
    case 0:
    case 1:
    case 2: 
    case 3:
    case 4:
    case 5:
        cout<<"a is between 0,5 and equals: "<<a<<"\n";
        break;
    //other case statements
    default:
        cout<<"a is not between the range or is not a good value\n"
        break;

Я вважаю за краще, якщо - інакше, якщо - ще заяви, але це справді залежить від вас. Якщо ви хочете використовувати функції як умови, або ви хочете тестувати щось на діапазоні, масиві чи векторі та / або ви не проти мати справу зі складним вкладом, я рекомендую використовувати, якщо інше блокує. Якщо ви хочете перевірити окремі значення або вам потрібен чистий і легкий для читання блок, я рекомендую вам використовувати блоки корпусу switch ().

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

Я знаю його старе, але

public class SwitchTest {
static final int max = 100000;

public static void main(String[] args) {

int counter1 = 0;
long start1 = 0l;
long total1 = 0l;

int counter2 = 0;
long start2 = 0l;
long total2 = 0l;
boolean loop = true;

start1 = System.currentTimeMillis();
while (true) {
  if (counter1 == max) {
    break;
  } else {
    counter1++;
  }
}
total1 = System.currentTimeMillis() - start1;

start2 = System.currentTimeMillis();
while (loop) {
  switch (counter2) {
    case max:
      loop = false;
      break;
    default:
      counter2++;
  }
}
total2 = System.currentTimeMillis() - start2;

System.out.println("While if/else: " + total1 + "ms");
System.out.println("Switch: " + total2 + "ms");
System.out.println("Max Loops: " + max);

System.exit(0);
}
}

Варіація зміни циклу сильно змінюється:

Хоча якщо / ще: 5ms перемикання: 1ms Максимальна кількість циклів: 100000

Хоча якщо / ще: 5ms Перемикач: 3ms Максимальна кількість циклів: 1000000

Хоча якщо / ще: 5ms Перемикач: 14ms Максимальна кількість циклів: 10000000

Хоча якщо / ще: 5ms Перемикач: 149ms Максимальна кількість циклів: 100000000

(додайте ще заяви, якщо хочете)