Perché l'istruzione switch è stata progettata per richiedere un'interruzione?

Dato un semplice switch switch

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

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

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

L'assenza di una dichiarazione di rottura nel caso 2, implica che l'esecuzione continuerà all'interno del codice per il caso 3. Questo non è un incidente; è stato progettato in questo modo. Perché sono state prese queste decisioni? Quale vantaggio offre questo rispetto alla presenza di una semantica di interruzione automatica per i blocchi? Qual era la logica?

Molte risposte sembrano concentrarsi sulla capacità di fallire come motivo per richiedere l' breakaffermazione.

Credo che sia stato semplicemente un errore, in gran parte dovuto al fatto che quando C è stato progettato non c'era molta esperienza su come questi costrutti sarebbero stati usati.

Peter Van der Linden illustra il caso nel suo libro "Expert C Programming":

Abbiamo analizzato le fonti del compilatore Sun C per vedere con quale frequenza veniva utilizzato il fall fall default. Il front-end del compilatore Sun ANSI C ha 244 istruzioni switch, ognuna delle quali ha una media di sette casi. La caduta avviene solo nel 3% di tutti questi casi.

In altre parole, il normale comportamento dell'interruttore è errato nel 97% dei casi. Non è solo in un compilatore - al contrario, dove fall through è stato utilizzato in questa analisi è stato spesso per situazioni che si verificano più frequentemente in un compilatore rispetto ad altri software, ad esempio, quando si compilano operatori che possono avere uno o due operandi :

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

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

Il case fall through è così ampiamente riconosciuto come un difetto che esiste persino una convenzione di commento speciale, mostrata sopra, che dice alla lanugine "questo è davvero uno di quei 3% dei casi in cui si desiderava il fall through".

Penso che sia stata una buona idea richiedere a C # un'istruzione esplicita per il salto alla fine di ogni blocco maiuscolo (pur consentendo l'accatastamento di più etichette maiuscole, purché vi sia un solo blocco di istruzioni). In C # puoi comunque far cadere un caso in un altro - devi solo rendere esplicito il fall thru saltando al caso successivo usando a goto.

Peccato che Java non abbia colto l'occasione per uscire dalla semantica C.

In molti modi c è solo un'interfaccia pulita per gli idiomi di assemblaggio standard. Quando si scrive il controllo del flusso guidato dalla tabella di salto, il programmatore ha la possibilità di saltare o saltare fuori dalla "struttura di controllo" e un salto richiede un'istruzione esplicita.

Quindi, c fa la stessa cosa ...

Per implementare il dispositivo Duff, ovviamente:

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

Se i casi sono stati progettati per rompersi in modo implicito, non si potrebbe avere fallimenti.

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

Se l'interruttore fosse progettato per rompersi implicitamente dopo ogni caso, non avresti scelta. La struttura della custodia è stata progettata per essere più flessibile.

Le istruzioni case in istruzioni switch sono semplicemente etichette.

Quando si attiva un valore, l'istruzione switch fa essenzialmente un goto sull'etichetta con il valore corrispondente.

Ciò significa che l'interruzione è necessaria per evitare di passare al codice sotto l'etichetta successiva.

Per quanto riguarda il motivo per cui è stato implementato in questo modo - la natura fall-through di un'istruzione switch può essere utile in alcuni scenari. Per esempio:

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;

Per consentire cose come:

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

Pensa alla caseparola chiave come gotoun'etichetta ed è molto più naturale.

Elimina la duplicazione del codice quando diversi casi devono eseguire lo stesso codice (o lo stesso codice in sequenza).

Dal momento che a livello di linguaggio assembly non importa se si interrompe tra di loro o meno non vi è alcun sovraccarico zero per fallire comunque casi, quindi perché non consentirli poiché offrono vantaggi significativi in ​​alcuni casi.

Mi è capitato di imbattermi in un caso di assegnazione di valori in vettori a strutture: doveva essere fatto in modo tale che se il vettore di dati fosse più corto del numero di membri di dati nella struttura, il resto dei membri rimarrebbe in il loro valore predefinito. In quel caso omettere breakera abbastanza utile.

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

Come molti hanno specificato qui, è per consentire a un singolo blocco di codice di funzionare per più casi. Questo dovrebbe essere un evento più comune per le istruzioni switch rispetto al "blocco di codice per caso" specificato nell'esempio.

Se hai un blocco di codice per caso senza fall-through, forse dovresti considerare l'uso di un blocco if-elseif-else, poiché sembrerebbe più appropriato.