Чому оператор перемикання розрахований на необхідність перерви?

Дано просту заяву про перемикання

switch (int)
{
    case 1 :
    {
        printf("1\n");
        break;
    }

    case 2 : 
    {
        printf("2\n");
    }

    case 3 : 
    {
        printf("3\n");
    }
}

Відсутність заяви про перерву у випадку 2 означає, що виконання триватиме всередині коду для випадку 3. Це не випадковість; це було розроблено саме так. Чому було прийнято таке рішення? Яку користь це забезпечує від автоматичного семантичного розриву для блоків? Що було обґрунтуванням?

Здається, багато відповідей зосереджуються на здатності пропасти як причину вимагати breakзаяви.

Я вважаю, що це була просто помилка, багато в чому пов'язана з тим, що коли проектувався C, не було майже такого досвіду, як використовувати ці конструкції.

Петер Ван дер Лінден говорить про це у своїй книзі "Експертне програмування на C":

Ми проаналізували джерела компілятора Sun C, щоб побачити, як часто використовувалося падіння за замовчуванням. Передній кінець компілятора Sun ANSI C має 244 заяви комутатора, кожен з яких має в середньому сім випадків. Падіння відбувається лише у 3% усіх цих випадків.

Іншими словами, нормальна поведінка комутатора неправильна 97% часу. Справа не тільки в компіляторі - навпаки, коли в цьому аналізі використовувався пропуск, це часто траплялося для ситуацій, які трапляються частіше в компіляторі, ніж в іншому програмному забезпеченні, наприклад, при складанні операторів, які можуть мати один або два операнди :

switch (operator->num_of_operands) {
    case 2: process_operand( operator->operand_2);
              /* FALLTHRU */

    case 1: process_operand( operator->operand_1);
    break;
}

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

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

Дуже погано Java не скористалася можливістю відірватися від семантики С.

Багато в чому c - це просто чистий інтерфейс до стандартних ідіом складання. Під час написання керованого керування потоком керування таблицею програміст має можливість вибиватися або вистрибувати з "керуючої структури", а для вистрибування потрібна чітка інструкція.

Отже, c робить те саме ...

Для реалізації пристрою Даффа, очевидно:

dsend(to, from, count)
char *to, *from;
int count;
{
    int n = (count + 7) / 8;
    switch (count % 8) {
    case 0: do { *to = *from++;
    case 7:      *to = *from++;
    case 6:      *to = *from++;
    case 5:      *to = *from++;
    case 4:      *to = *from++;
    case 3:      *to = *from++;
    case 2:      *to = *from++;
    case 1:      *to = *from++;
               } while (--n > 0);
    }
}

Якщо справи були розроблені неявно, то ви не могли б провалитися.

case 0:
case 1:
case 2:
    // all do the same thing.
    break;
case 3:
case 4:
    // do something different.
    break;
default:
    // something else entirely.

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

Оператори справи в операторах переключення - це просто мітки.

Коли ви включаєте значення, оператор switch по суті робить goto на мітку зі значенням відповідності.

Це означає, що перерва необхідний, щоб не переходити до коду під наступною міткою.

Що стосується причини, по якій він був реалізований таким чином - характер пропускання оператора перемикання може бути корисним у деяких сценаріях. Наприклад:

case optionA:
    // optionA needs to do its own thing, and also B's thing.
    // Fall-through to optionB afterwards.
    // Its behaviour is a superset of B's.
case optionB:
    // optionB needs to do its own thing
    // Its behaviour is a subset of A's.
    break;
case optionC:
    // optionC is quite independent so it does its own thing.
    break;

Щоб дозволити такі речі, як:

switch(foo) {
case 1:
    /* stuff for case 1 only */
    if (0) {
case 2:
    /* stuff for case 2 only */
    }
    /* stuff for cases 1 and 2 */
case 3:
    /* stuff for cases 1, 2, and 3 */
}

Подумайте про caseключове слово як gotoмітку, і воно набагато природніше.

Це виключає дублювання коду, коли кілька випадків потребують виконання одного і того ж коду (або того ж коду в послідовності).

Оскільки на рівні мови асемблери не важливо, перерваєтесь між кожним чи ні, є нульові накладні витрати на випадкові випадки, то чому б не допустити їх, оскільки вони надають значні переваги в певних випадках.

Я випадково наткнувся на випадок присвоєння значень векторам структурам: це потрібно було зробити так, що якщо вектор даних буде коротшим за кількість членів даних у структурі, решта членів залишаться в їх значення за замовчуванням. У цьому випадку пропущення breakбуло досить корисним.

switch (nShorts)
{
case 4: frame.leadV1    = shortArray[3];
case 3: frame.leadIII   = shortArray[2];
case 2: frame.leadII    = shortArray[1];
case 1: frame.leadI     = shortArray[0]; break;
default: TS_ASSERT(false);
}

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

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