Warum wurde die switch-Anweisung so konzipiert, dass sie eine Pause benötigt?

Question 1

Gegeben sei eine einfache switch-Anweisung

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

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

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

Das Fehlen einer break-Anweisung in Fall 2 impliziert, dass die Ausführung innerhalb des Codes für Fall 3 fortgesetzt wird. Dies ist kein Unfall; es war so konzipiert. Warum wurden diese Entscheidungen getroffen? Welchen Vorteil bietet dies gegenüber einer automatischen Unterbrechungssemantik für die Blöcke? Was war die Begründung?

Question 2

Viele Antworten scheinen sich auf die Fähigkeit zum Durchfallen zu konzentrieren Grund für die Forderung nach break Aussage.

Ich glaube, es war einfach ein Fehler, der größtenteils darauf zurückzuführen ist, dass es beim Entwurf von C nicht annähernd so viel Erfahrung mit der Verwendung dieser Konstrukte gab.

Peter Van der Linden argumentiert in seinem Buch “Expert C Programming”:

Wir haben die Sun-C-Compiler-Quellen analysiert, um zu sehen, wie oft der standardmäßige Fall-Through verwendet wurde. Das Sun-ANSI-C-Compiler-Frontend hat 244 switch-Anweisungen, von denen jede durchschnittlich sieben Fälle hat. Durchfall tritt nur in 3 % aller dieser Fälle auf.

Mit anderen Worten, das normale Schaltverhalten ist falsch 97% der Zeit. Es ist nicht nur in einem Compiler – im Gegenteil, wo Fall Through in dieser Analyse verwendet wurde, war es oft für Situationen, die in einem Compiler häufiger vorkommen als in anderer Software, zum Beispiel beim Kompilieren von Operatoren, die entweder einen oder zwei Operanden haben können :
switch (operator->num_of_operands) {
    case 2: process_operand( operator->operand_2);
              /* FALLTHRU */

    case 1: process_operand( operator->operand_1);
    break;
}
Das Durchfallen von Gehäusen wird so weithin als Fehler anerkannt, dass es sogar eine spezielle Kommentarkonvention gibt, die oben gezeigt wird und Lint sagt: “Dies ist wirklich einer dieser 3% der Fälle, in denen ein Durchfallen erwünscht war.”

Ich denke, es war eine gute Idee für C#, eine explizite Sprunganweisung am Ende jedes Case-Blocks zu verlangen (während immer noch mehrere Case-Labels gestapelt werden können – solange es nur einen einzigen Block von Anweisungen gibt). In C# können Sie immer noch einen Fall in einen anderen durchfallen lassen – Sie müssen den Durchbruch nur explizit machen, indem Sie mit a zum nächsten Fall springen goto.

Schade, dass Java die Gelegenheit nicht genutzt hat, um von der C-Semantik abzuweichen.

Question 3

In vielerlei Hinsicht ist c nur eine saubere Schnittstelle zu Standard-Assembler-Idiomen. Beim Schreiben der Sprungtabellen-gesteuerten Ablaufsteuerung hat der Programmierer die Wahl, durch die “Steuerungsstruktur” zu fallen oder aus ihr herauszuspringen, und ein Herausspringen erfordert eine explizite Anweisung.

Also, c macht das gleiche …

Question 4

Um Duffs Gerät zu implementieren, natürlich:

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

Question 5

Wenn Fälle so konzipiert waren, dass sie implizit brechen, könnten Sie keinen Fallthrough haben.

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

Wenn der Schalter so konzipiert wäre, dass er nach jedem Fall implizit ausbricht, hätten Sie keine Wahl. Der Schaltkastenaufbau wurde so konzipiert, dass er flexibler sein soll.

Question 6

Die case-Anweisungen in switch-Anweisungen sind einfach Labels.

Wenn Sie einen Wert einschalten, macht die switch-Anweisung im Wesentlichen a gehe zu auf das Etikett mit dem passenden Wert.

Das bedeutet, dass der Break notwendig ist, um nicht zum Code unter dem nächsten Label zu gelangen.

Was den Grund angeht warum Es wurde auf diese Weise implementiert – die Fall-Through-Natur einer Switch-Anweisung kann in einigen Szenarien nützlich sein. Zum Beispiel:

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;

Question 7

Dinge zuzulassen wie:

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

Denken Sie an die case Stichwort als goto Label und es kommt viel natürlicher.

Question 8

Es eliminiert Codeduplizierung, wenn mehrere Fälle denselben Code (oder denselben Code nacheinander) ausführen müssen.

Da es auf der Ebene der Assemblersprache egal ist, ob Sie zwischen den einzelnen Fällen umbrechen oder nicht, gibt es sowieso keinen Overhead für Fall-Through-Fälle, also warum nicht zulassen, da sie in bestimmten Fällen erhebliche Vorteile bieten.