Dlaczego musimy używać przełącznika przerwania?

Kto zdecydował (i na podstawie jakich pojęć), że switchkonstrukcja (w wielu językach) musi być użyta breakw każdym stwierdzeniu?

Dlaczego musimy napisać coś takiego:

switch(a)
{
    case 1:
        result = 'one';
        break;
    case 2:
        result = 'two';
        break;
    default:
        result = 'not determined';
        break;
}

(zauważyłem to w PHP i JS; prawdopodobnie używa wielu innych języków)

Jeśli switchjest to alternatywa if, dlaczego nie możemy użyć tej samej konstrukcji, co dla if? To znaczy:

switch(a)
{
    case 1:
    {
        result = 'one';
    }
    case 2:
    {
        result = 'two';
    }
    default:
    {
        result = 'not determined';
    }
}

Mówi się, że breakuniemożliwia wykonanie bloku następującego po bieżącym. Ale czy ktoś naprawdę wpadł na sytuację, w której istniała potrzeba wykonania bieżącego bloku i kolejnych? Ja nie. Dla mnie breakzawsze tam jest. W każdym bloku. W każdym kodzie.

C był jednym z pierwszych języków, w którym switchoświadczenie było w tej formie, i wszystkie inne główne języki odziedziczyły je stamtąd, przeważnie decydując się zachować domyślną semantykę C - albo nie zastanawiały się nad zaletami jego zmiany, albo osądzały mniej ważne niż zachowanie, do którego wszyscy byli przyzwyczajeni.

Co do tego, dlaczego C został zaprojektowany w ten sposób, prawdopodobnie wynika on z koncepcji C jako „przenośnego zestawu”. switchStwierdzenie jest w zasadzie poboru tabeli oddziału i stół oddział ma również niejawna jesieni-through i wymaga dodatkowej instrukcji skoku, aby tego uniknąć.

Zasadniczo projektanci C również postanowili zachować semantykę asemblera jako domyślną.

Ponieważ switchnie jest alternatywą dla if ... elseoświadczeń w tych językach.

Używając switch, możemy dopasować więcej niż jeden warunek na raz, co jest bardzo cenione w niektórych przypadkach.

Przykład:

public Season SeasonFromMonth(Month month)
{
    Season season;
    switch (month)
    {
        case Month.December:
        case Month.January:
        case Month.February:
            season = Season.Winter;
            break;

        case Month.March:
        case Month.April:
        case Month.May:
            season = Season.Spring;
            break;

        case Month.June:
        case Month.July:
        case Month.August:
            season = Season.Summer;
            break;

        default:
            season = Season.Autumn;
            break;
    }

    return season;
}

To pytanie zostało zadane w przypadku przepełnienia stosu w kontekście C: Dlaczego instrukcja switch została zaprojektowana tak, aby wymagała przerwy?

Podsumowując przyjętą odpowiedź, prawdopodobnie był to błąd. Większość innych języków prawdopodobnie właśnie zastosowało się do C. Jednak niektóre języki, takie jak C #, wydają się naprawiać to, pozwalając na awarię - ale tylko wtedy, gdy programista wyraźnie to mówi (źródło: link powyżej, nie mówię w języku C #) .

Odpowiem przykładem. Jeśli chcesz podać liczbę dni dla każdego miesiąca w roku, oczywiste jest, że niektóre miesiące mają 31, około 30 i 1 28/29. Tak by wyglądało

switch(month) {
    case 4:
    case 6:
    case 9:
    case 11;
        days = 30;
        break;
    case 2:
        //Find out if is leap year( divisible by 4 and all that other stuff)
        days = 28 or 29;
        break;
    default:
        days = 31;
}

Jest to przykład, w którym wiele przypadków ma ten sam efekt i wszystkie są zgrupowane razem. Istniał oczywiście powód wyboru słowa kluczowego break, a nie argumentu if ... else if construct.

Najważniejszą rzeczą do odnotowania tutaj jest to, że instrukcja switch z wieloma podobnymi przypadkami nie jest jeśli… jeśli… jeśli… jeśli… jeśli… w każdym przypadku, ale jeśli (1, 2, 3) ... inaczej jeśli (4,5,6) jeszcze ...

Istnieją dwie sytuacje, w których może wystąpić „wpadnięcie” z jednej skrzynki do drugiej - pusta skrzynka:

switch ( ... )
{
  case 1:
  case 2:
    do_something_for_1_and_2();
    break;
  ...
}

i niepusty pojemnik

switch ( ... )
{
  case 1:
    do_something_for_1();
    /* Deliberately fall through */
  case 2:
    do_something_for_1_and_2();
    break;
...
}

Niezależnie od odniesienia do Urządzenia Duffa , uzasadnione przypadki dla drugiego przypadku są nieliczne i daleko od nich, i generalnie są zabronione przez standardy kodowania i oznaczone podczas analizy statycznej. A tam, gdzie to jest znalezione, jest to najczęściej spowodowane pominięciem litery break.

Ten pierwszy jest całkowicie rozsądny i powszechny.

Szczerze mówiąc, nie widzę powodu, dla którego potrzebuję breakparsera i języka, wiedząc, że puste ciało-sprawa to upadek, podczas gdy niepuste pudełko jest samodzielne.

Szkoda, że ​​panel ISO C wydaje się bardziej zajęty dodawaniem do języka nowych (niechcianych) i źle zdefiniowanych funkcji, niż naprawianiem nieokreślonych, nieokreślonych lub zdefiniowanych przez implementację funkcji, nie wspominając o nielogiczności.

Brak wymuszania breakdopuszcza wielu rzeczy, które w innym przypadku mogłyby być trudne. Inni zauważyli przypadki grupowania, dla których istnieje szereg spraw niebanalnych.

Jednym z przypadków, w których konieczne breakjest nieużywanie, jest Urządzenie Duffa . Służy do „ rozwijania ” pętli, w których może przyspieszyć operacje, ograniczając liczbę wymaganych porównań. Wierzę, że początkowe użycie pozwoliło na funkcjonalność, która wcześniej była zbyt wolna z całkowicie zwiniętą pętlą. W niektórych przypadkach zamienia rozmiar kodu na szybkość.

Dobrą praktyką jest zastąpienie breakodpowiedniego komentarzem, jeśli sprawa ma jakiś kod. W przeciwnym razie ktoś naprawi brakujące narzędzie breaki wprowadzi błąd.

W C, gdzie wydaje się, że początek, blok kodu switchinstrukcji nie jest specjalną konstrukcją. Jest to normalny blok kodu, podobnie jak blok pod ifinstrukcją.

switch ()
{
}

if ()
{
}

casei defaultprzeskakują etykiety wewnątrz tego bloku, szczególnie związane z switch. Są obsługiwane tak jak normalne etykiety skoku goto. Ważna jest tutaj jedna konkretna zasada: etykiety skoków mogą znajdować się prawie wszędzie w kodzie, bez zakłócania przepływu kodu.

Jako zwykły blok kodu nie musi to być instrukcja złożona. Etykiety są również opcjonalne. Są to ważne switchoświadczenia w katalogu C:

switch (a)
    case 1: Foo();

switch (a)
    Foo();

switch (a)
{
    Foo();
}

Sam standard C podaje to jako przykład (6.8.4.2):

switch (expr) 
{ 
    int i = 4; 
    f(i); 
  case 0: 
    i=17; 
    /*falls through into default code */ 
  default: 
    printf("%d\n", i); 
} 

W sztucznym fragmencie programu obiekt o identyfikatorze i istnieje z automatycznym czasem przechowywania (w bloku), ale nigdy nie jest inicjowany, a zatem jeśli wyrażenie kontrolne ma wartość niezerową, wywołanie funkcji printf uzyska dostęp do nieokreślonej wartości. Podobnie nie można nawiązać połączenia z funkcją f.

Co więcej, defaultjest również etykietą skoku, a zatem może być w dowolnym miejscu, bez potrzeby bycia ostatnim przypadkiem.

To wyjaśnia również urządzenie Duffa:

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

Skąd ta awaria? Ponieważ w normalnym przepływie kodu w normalnym bloku kodu oczekuje się przejścia do następnej instrukcji , tak jak można tego oczekiwać w ifbloku kodu.

if (a == b)
{
    Foo();
    /* "Fall-through" to Bar expected here. */
    Bar();
}

switch (a)
{
    case 1: 
        Foo();
        /* Automatic break would violate expected code execution semantics. */
    case 2:
        Bar();
}

Domyślam się, że powodem tego była łatwość wdrożenia. Nie potrzebujesz specjalnego kodu do parsowania i kompilowania switchbloku, dbając o specjalne reguły. Po prostu parsujesz go jak każdy inny kod i musisz tylko dbać o etykiety i wybór skoku.

Ciekawym pytaniem uzupełniającym z tego wszystkiego jest to, czy następujące zagnieżdżone instrukcje wypisują „Gotowe”. albo nie.

int a = 10;

switch (a)
{
    switch (a)
    {
        case 10: printf("Done.\n");
    }
}

Norma C dba o to (6.8.4.2.4):

Etykieta lub domyślna etykieta jest dostępna tylko w najbliższej załączającej instrukcji switch.

Kilka osób wspomniało już o dopasowaniu wielu warunków, co jest bardzo cenne od czasu do czasu. Jednak zdolność dopasowania wielu warunków niekoniecznie wymaga, abyś robił dokładnie to samo z każdym pasującym warunkiem. Rozważ następujące:

switch (someCase)
{
    case 1:
    case 2:
        doSomething1And2();
        break;

    case 3:
        doSomething3();

    case 4:
        doSomething3And4();
        break;

    default:
        throw new Error("Invalid Case");
}

Istnieją dwa różne sposoby dopasowania zestawów wielu warunków. W przypadku warunków 1 i 2 po prostu przechodzą do dokładnie tego samego wykresu kodu i robią dokładnie to samo. Jednak z warunkami 3 i 4, mimo że oba kończą się połączeniem doSomething3And4(), tylko 3 połączenia doSomething3().

Aby odpowiedzieć na dwa twoje pytania.

Dlaczego C potrzebuje przerw?

Sprowadza się do korzeni Cs jako „przenośnego asemblera”. Gdzie taki kod psudo był powszechny: -

    targets=(addr1,addr2,addr3);
    opt = 1  ## or 0 or 2
switch:
    br targets[opt]  ## go to addr2 
addr1:
    do 1stuff
    br switchend
addr2:
    do 2stuff
    br switchend
addr3
    do 3stuff
switchend:
    ......

instrukcja switch została zaprojektowana w celu zapewnienia podobnej funkcjonalności na wyższym poziomie.

Czy kiedykolwiek mamy przełączniki bez przerw?

Tak, jest to dość powszechne i istnieje kilka przypadków użycia;

Po pierwsze, możesz chcieć podjąć to samo działanie w kilku przypadkach. Robimy to, układając skrzynki jedna na drugiej:

case 6:
case 9:
    // six or nine code

Innym przypadkiem użycia powszechnym w automatach stanów jest to, że po przetworzeniu jednego stanu natychmiast chcemy wprowadzić i przetworzyć inny stan:

case 9:
    crashed()
    newstate=10;
case 10:
    claim_damage();
    break;

Instrukcja break jest instrukcją skokową, która pozwala użytkownikowi wyjść z najbliższego załączającego przełącznika (w twoim przypadku), podczas gdy, do, for lub foreach. to takie proste.

Myślę, że przy wszystkich powyższych tekstach - głównym rezultatem tego wątku jest to, że jeśli chcesz zaprojektować nowy język - domyślnie powinno być tak, że nie musisz dodawać breakinstrukcji, a kompilator potraktuje to tak, jakbyś to zrobił.

Jeśli chcesz ten rzadki przypadek, w którym chcesz przejść do następnej sprawy - po prostu podaj continueoświadczenie.

Można to poprawić, tak że tylko jeśli użyjesz nawiasów klamrowych wewnątrz obudowy, nie będzie to kontynuowane, więc przykład z powyższymi miesiącami kilku przypadków wykonujących ten sam dokładny kod - zawsze działałby zgodnie z oczekiwaniami bez potrzeby continue.