Dlaczego instrukcja Switch została zaprojektowana tak, aby wymagała przerwy?

Biorąc pod uwagę prostą instrukcję przełącznika

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

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

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

Brak instrukcji break w przypadku 2 oznacza, że ​​wykonanie będzie kontynuowane wewnątrz kodu dla przypadku 3. To nie jest przypadek; został zaprojektowany w ten sposób. Dlaczego podjęto takie decyzje? Jakie to daje korzyści w porównaniu z automatyczną semantyczną przerwą dla bloków? Jaki był powód?

Wiele odpowiedzi wydaje się skupiać się na zdolności do upadku jako na przyczynie żądania breakstwierdzenia.

Uważam, że był to po prostu błąd, głównie dlatego, że gdy projektowano C, nie było tak dużego doświadczenia w zakresie wykorzystania tych konstrukcji.

Peter Van der Linden przedstawia taki przypadek w swojej książce „Expert C Programming”:

Przeanalizowaliśmy źródła kompilatora Sun C, aby zobaczyć, jak często używany był domyślny błąd. Interfejs kompilatora Sun ANSI C ma 244 instrukcje przełączające, z których każda ma średnio siedem przypadków. Upadek występuje tylko w 3% wszystkich tych przypadków.

Innymi słowy, normalne zachowanie przełącznika jest nieprawidłowe w 97% przypadków. Nie dotyczy to tylko kompilatora - wręcz przeciwnie, tam, gdzie fall through używano w tej analizie, często dotyczyło to sytuacji, które występują częściej w kompilatorze niż w innym oprogramowaniu, na przykład podczas kompilowania operatorów, które mogą mieć jeden lub dwa operandy :

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

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

Upadek przypadku jest tak powszechnie uznawany za wadę, że istnieje nawet specjalna konwencja komentarzy, pokazana powyżej, która mówi lintowi, że „jest to naprawdę jeden z tych 3% przypadków, w których upadek był pożądany”.

Myślę, że dobrym pomysłem dla C # było wymaganie jawnej instrukcji skoku na końcu każdego bloku przypadku (przy jednoczesnym umożliwieniu układania wielu etykiet przypadków - o ile istnieje tylko jeden blok instrukcji). W języku C # nadal możesz mieć jeden przypadek przechodzić do drugiego - wystarczy, że przejdziesz bezpośrednio przez przejście do następnego przypadku przy użyciu pliku goto.

Szkoda, że ​​Java nie skorzystała z okazji, aby zerwać z semantyką C.

Na wiele sposobów c jest po prostu przejrzystym interfejsem do standardowych idiomów asemblera. Pisząc sterowanie przepływem sterowane tablicą skoków, programista ma do wyboru wypadnięcie lub wyskoczenie ze „struktury sterowania”, a wyskoczenie wymaga wyraźnej instrukcji.

Więc c robi to samo ...

Aby wdrożyć urządzenie Duffa, oczywiście:

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

Gdyby sprawy miały załamać się niejawnie, to nie można by tego dokonać.

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

Gdyby przełącznik został zaprojektowany tak, aby wyłamać się niejawnie po każdym przypadku, nie miałbyś wyboru. Konstrukcja obudowy przełącznika została zaprojektowana w taki sposób, aby była bardziej elastyczna.

Instrukcje case w instrukcjach switch są po prostu etykietami.

Po przełączeniu na wartości, instrukcja switch zasadniczo robi goto do etykiety o wartości dopasowania.

Oznacza to, że przerwa jest konieczna, aby uniknąć przejścia do kodu pod następną etykietą.

Jeśli chodzi o powód, dla którego została zaimplementowana w ten sposób - upadkowy charakter instrukcji przełącznika może być przydatny w niektórych scenariuszach. Na przykład:

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;

Aby zezwolić na takie rzeczy, jak:

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 */
}

Pomyśl o casesłowie kluczowym jak o gotoetykiecie i jest to o wiele bardziej naturalne.

Eliminuje powielanie kodu, gdy kilka przypadków musi wykonać ten sam kod (lub ten sam kod w kolejności).

Ponieważ na poziomie języka asemblerowego nie ma znaczenia, czy przerwiesz każdy z nich, czy też nie, i tak nie ma żadnego narzutu za upadek przypadków, więc dlaczego nie pozwolić im, skoro oferują one znaczące korzyści w niektórych przypadkach.

Zdarzyło mi się natknąć się na przypadek przypisywania wartości w wektorach do struktur: trzeba było to zrobić w taki sposób, że jeśli wektor danych byłby krótszy niż liczba członków danych w strukturze, reszta członków pozostałaby w ich wartość domyślna. W takim przypadku pomijanie breakbyło całkiem przydatne.

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

Jak wiele osób tutaj wskazało, ma to pozwolić na działanie pojedynczego bloku kodu w wielu przypadkach. To powinno być częstsze występowanie do swoich sprawozdań przełączników niż „bloku kodu na wszelki wypadek” można określić w swoim przykładzie.

Jeśli masz blok kodu na przypadek bez upadku, być może powinieneś rozważyć użycie bloku if-elseif-else, ponieważ wydaje się to bardziej odpowiednie.