Instrukcja Switch: czy wartość domyślna musi być ostatnim przypadkiem?

Rozważ następujące switchstwierdzenie:

switch( value )
{
  case 1:
    return 1;
  default:
    value++;
    // fall-through
  case 2:
    return value * 2;
}

Ten kod jest kompilowany, ale czy jest prawidłowy (= zdefiniowane zachowanie) dla C90 / C99? Nigdy nie widziałem kodu, w którym domyślny przypadek nie jest ostatnim przypadkiem.

EDYCJA:
Jak piszą Jon Cage i KillianDS : to jest naprawdę brzydki i zagmatwany kod i jestem tego świadomy. Interesuje mnie tylko ogólna składnia (czy jest zdefiniowana?) I oczekiwane dane wyjściowe.

Standard C99 nie jest na ten temat jednoznaczny, ale biorąc wszystkie fakty razem, jest całkowicie ważny.

A casei defaultetykieta są odpowiednikiem gotoetykiety. Patrz 6.8.1 Oznakowane oświadczenia. Szczególnie interesujący jest 6.8.1.4, który umożliwia wspomniane już urządzenie Duffa:

Każda instrukcja może być poprzedzona przedrostkiem, który deklaruje identyfikator jako nazwę etykiety. Etykiety same w sobie nie zmieniają przepływu kontroli, która przebiega przez nie bez przeszkód.

Edycja : kod w przełączniku nie jest niczym specjalnym; jest to normalny blok kodu, jak w instrukcji if, z dodatkowymi etykietami skoku. To wyjaśnia zachowanie upadku i dlaczego breakjest to konieczne.

6.8.4.2.7 podaje nawet przykład:

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, którego identyfikatorem jest i, istnieje z automatycznym czasem trwania (w bloku), ale nigdy nie jest inicjowany, a zatem jeśli wyrażenie sterujące ma wartość różną od zera, wywołanie funkcji printf będzie miało dostęp do nieokreślonej wartości. Podobnie, wywołanie funkcji f nie może zostać osiągnięte.

Stałe wielkości liter muszą być unikalne w instrukcji switch:

6.8.4.2.3 Wyrażenie każdej etykiety przypadku będzie wyrażeniem stałym w postaci liczby całkowitej i żadne dwa wyrażenia stałe przypadku w tej samej instrukcji przełączającej nie będą miały takiej samej wartości po konwersji. Instrukcja switch może zawierać co najwyżej jedną etykietę domyślną.

Wszystkie przypadki są oceniane, a następnie przeskakuje do domyślnej etykiety, jeśli jest podana:

6.8.4.2.5 Awanse liczb całkowitych są przeprowadzane na wyrażeniu sterującym. Stałe wyrażenie w każdej etykiecie przypadku jest konwertowane na promowany typ wyrażenia sterującego. Jeśli przekonwertowana wartość jest zgodna z wartością promowanego wyrażenia sterującego, sterowanie przeskakuje do instrukcji następującej po dopasowanej etykiecie przypadku. W przeciwnym razie, jeśli istnieje etykieta domyślna, sterowanie przeskakuje do instrukcji z etykietą. Jeśli żadne przekształcone wyrażenie stałe wielkości liter nie pasuje i nie ma etykiety domyślnej, żadna część treści przełącznika nie jest wykonywana.

Instrukcje case i instrukcja default mogą występować w dowolnej kolejności w instrukcji switch. Klauzula domyślna jest klauzulą ​​opcjonalną, która jest dopasowywana, jeśli żadna ze stałych w instrukcjach case nie może zostać dopasowana.

Dobry przykład :-

switch(5) {
  case 1:
    echo "1";
    break;
  case 2:
  default:
    echo "2, default";
    break;
  case 3;
    echo "3";
    break;
}


Outputs '2,default'

bardzo przydatne, jeśli chcesz, aby twoje sprawy były prezentowane w logicznej kolejności w kodzie (jak w nie mówiąc przypadek 1, przypadek 3, przypadek 2 / domyślny), a twoje sprawy są bardzo długie, więc nie chcesz powtarzać całej sprawy kod na dole dla domyślnego

W niektórych przypadkach jest to ważne i bardzo przydatne.

Rozważ następujący kod:

switch(poll(fds, 1, 1000000)){
   default:
    // here goes the normal case : some events occured
   break;
   case 0:
    // here goes the timeout case
   break;
   case -1:
     // some error occurred, you have to check errno
}

Chodzi o to, że powyższy kod jest bardziej czytelny i wydajny niż kaskadowy if. Mógłbyś to defaultzakończyć, ale jest to bezcelowe, ponieważ skupi twoją uwagę na przypadkach błędów zamiast normalnych przypadków (tak jest w tym defaultprzypadku).

Właściwie to nie jest taki dobry przykład, ponieważ pollwiesz, ile zdarzeń może wystąpić najwyżej. Moje prawdziwe jest to, że tam są przypadki z określonego zestawu wartości wejściowych, gdzie istnieją „wyjątki” i normalnych przypadkach. Czy lepiej jest umieścić wyjątki lub normalne przypadki na pierwszym planie, to kwestia wyboru.

W dziedzinie oprogramowania myślę o innym bardzo zwykłym przypadku: rekurencji z pewnymi wartościami końcowymi. Jeśli możesz to wyrazić za pomocą przełącznika,default będzie zwykłą wartością zawierającą wywołanie rekurencyjne i wyróżnione elementy (pojedyncze przypadki) wartości końcowe. Zwykle nie ma potrzeby skupiania się na wartościach końcowych.

Innym powodem jest to, że kolejność przypadków może zmienić zachowanie skompilowanego kodu, co ma znaczenie dla wydajności. Większość kompilatorów wygeneruje skompilowany kod asemblera w tej samej kolejności, w jakiej kod pojawia się w przełączniku. To sprawia, że ​​pierwszy przypadek bardzo różni się od pozostałych: wszystkie przypadki z wyjątkiem pierwszego będą wymagały przeskoku, co spowoduje opróżnienie potoków procesora. Możesz to rozumieć tak, jak predyktor gałęzi, który domyślnie uruchamia pierwszy występujący przypadek w przełączniku. Jeśli przypadek jest znacznie bardziej powszechny niż inne, masz bardzo dobre powody, aby umieścić go jako pierwszy.

Czytanie komentarzy jest to szczególny powód, dla którego oryginalny plakat zadał to pytanie po przeczytaniu reorganizacji Branch Loop kompilatora Intel na temat optymalizacji kodu.

Wtedy stanie się to arbitrażem między czytelnością i wydajnością kodu. Prawdopodobnie lepiej jest zamieścić komentarz wyjaśniający przyszłemu czytelnikowi, dlaczego przypadek pojawia się jako pierwszy.

tak, to jest ważne, aw pewnych okolicznościach nawet przydatne. Generalnie, jeśli tego nie potrzebujesz, nie rób tego.

W instrukcji switch nie ma zdefiniowanej kolejności. Możesz patrzeć na przypadki jako na coś w rodzaju nazwanej etykiety, jak gotoetykieta. W przeciwieństwie do tego, co ludzie wydają się tutaj sądzić, w przypadku wartości 2 nie przeskakuje się do domyślnej etykiety. Aby zilustrować klasycznym przykładem, oto urządzenie Duffa , które jest plakatem potomnym skrajności switch/casew C.

send(to, from, count)
register short *to, *from;
register count;
{
  register 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);
  }
}

Jeden scenariusz, w którym uznałbym za stosowne umieszczenie „wartości domyślnej” w innym miejscu niż instrukcja końca przypadku, dotyczy automatu stanowego, w którym nieprawidłowy stan powinien zresetować maszynę i postępować tak, jakby był to stan początkowy. Na przykład:

przełącznik (stan_widżetu)
{
  domyślnie: / * Spadł z szyn - zresetuj i kontynuuj * /
    widget_state = WIDGET_START;
    / * Spadaj * /
  sprawa WIDGET_START:
    ...
    przerwa;
  etui WIDGET_WHATEVER:
    ...
    przerwa;
}

rozwiązanie alternatywne, jeśli nieprawidłowy stan nie powinien resetować maszyny, ale powinien być łatwo rozpoznawalny jako nieprawidłowy stan:

przełącznik (stan_widżetu)
{
  sprawa WIDGET_IDLE:
    widget_ready = 0;
    widget_hardware_off ();
    przerwa;
  sprawa WIDGET_START:
    ...
    przerwa;
  etui WIDGET_WHATEVER:
    ...
    przerwa;
  domyślna:
    widget_state = WIDGET_INVALID_STATE;
    / * Spadaj * /
  sprawa WIDGET_INVALID_STATE:
    widget_ready = 0;
    widget_hardware_off ();
    ... zrób wszystko, co konieczne, aby ustanowić „bezpieczny” stan
}

Kod w innym miejscu może następnie sprawdzić (widget_state == WIDGET_INVALID_STATE) i zapewnić wszelkie działania związane z raportowaniem błędów lub resetowaniem stanu, które wydają się odpowiednie. Na przykład kod paskowy stanu może wyświetlać ikonę błędu, a opcja menu „start widget”, która jest wyłączona w większości stanów bezczynności, może być włączona zarówno dla WIDGET_INVALID_STATE, jak i WIDGET_IDLE.

Wbijając inny przykład: może to być przydatne, jeśli „domyślny” jest nieoczekiwanym przypadkiem i chcesz zarejestrować błąd, ale także zrobić coś rozsądnego. Przykład z mojego własnego kodu:

  switch (style)
  {
  default:
    MSPUB_DEBUG_MSG(("Couldn't match dash style, using solid line.\n"));
  case SOLID:
    return Dash(0, RECT_DOT);
  case DASH_SYS:
  {
    Dash ret(shapeLineWidth, dotStyle);
    ret.m_dots.push_back(Dot(1, 3 * shapeLineWidth));
    return ret;
  }
  // more cases follow
  }

Istnieją przypadki, gdy konwertujesz ENUM na ciąg lub konwertujesz ciąg na wyliczenie w przypadku, gdy piszesz / czytasz do / z pliku.

Czasami trzeba ustawić jedną z wartości jako domyślną, aby pokryć błędy popełnione podczas ręcznej edycji plików.

switch(textureMode)
{
case ModeTiled:
default:
    // write to a file "tiled"
    break;

case ModeStretched:
    // write to a file "stretched"
    break;
}

defaultWarunek może być wszędzie w przełączniku, że klauzula przypadek może istnieć. Nie jest wymagane, aby była to ostatnia klauzula. Widziałem kod, który ustawił wartość domyślną jako pierwszą klauzulę. Jest case 2:wykonywany normalnie, mimo że klauzula default jest nad nim.

W ramach testu umieściłem przykładowy kod w funkcji, wywołałem test(int value){}i uruchomiłem:

  printf("0=%d\n", test(0));
  printf("1=%d\n", test(1));
  printf("2=%d\n", test(2));
  printf("3=%d\n", test(3));
  printf("4=%d\n", test(4));

Wynik to:

0=2
1=1
2=4
3=8
4=10

Jest ważny, ale raczej paskudny. Sugerowałbym, że generalnie złe jest zezwalanie na upadki, ponieważ może to prowadzić do bardzo niechlujnego kodu spaghetti.

Prawie na pewno lepiej jest rozbić te przypadki na kilka instrukcji switch lub mniejszych funkcji.

[edytuj] @Tristopia: Twój przykład:

Example from UCS-2 to UTF-8 conversion 

r is the destination array, 
wc is the input wchar_t  

switch(utf8_length) 
{ 
    /* Note: code falls through cases! */ 
    case 3: r[2] = 0x80 | (wc & 0x3f); wc >>= 6; wc |= 0x800; 
    case 2: r[1] = 0x80 | (wc & 0x3f); wc >>= 6; wc |= 0x0c0; 
    case 1: r[0] = wc;
}

byłoby jaśniejsze co do jego intencji (myślę), gdyby zostało napisane w ten sposób:

if( utf8_length >= 1 )
{
    r[0] = wc;

    if( utf8_length >= 2 )
    {
        r[1] = 0x80 | (wc & 0x3f); wc >>= 6; wc |= 0x0c0; 

        if( utf8_length == 3 )
        {
            r[2] = 0x80 | (wc & 0x3f); wc >>= 6; wc |= 0x800; 
        }
    }
}   

[edit2] @Tristopia: Twój drugi przykład jest prawdopodobnie najczystszym przykładem dobrego wykorzystania do kontynuacji:

for(i=0; s[i]; i++)
{
    switch(s[i])
    {
    case '"': 
    case '\'': 
    case '\\': 
        d[dlen++] = '\\'; 
        /* fall through */ 
    default: 
        d[dlen++] = s[i]; 
    } 
}

... ale osobiście podzieliłbym rozpoznawanie komentarzy na jego własną funkcję:

bool isComment(char charInQuestion)
{   
    bool charIsComment = false;
    switch(charInQuestion)
    {
    case '"': 
    case '\'': 
    case '\\': 
        charIsComment = true; 
    default: 
        charIsComment = false; 
    } 
    return charIsComment;
}

for(i=0; s[i]; i++)
{
    if( isComment(s[i]) )
    {
        d[dlen++] = '\\'; 
    }
    d[dlen++] = s[i]; 
}