Warum sollte die switch-Anweisung eine Pause benötigen?

Gegeben 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 wurde so entworfen. Warum wurden diese Entscheidungen getroffen? Welchen Vorteil bietet dies gegenüber einer automatischen Unterbrechungssemantik für die Blöcke? Was war die Begründung?

Viele Antworten scheinen sich auf die Fähigkeit zu konzentrieren, als Grund für die Forderung nach dem Durchfallen zu fallenbreak Aussage .

Ich glaube, es war einfach ein Fehler, vor allem, weil bei der Entwicklung von C nicht annähernd so viel Erfahrung mit der Verwendung dieser Konstrukte vorhanden war.

Peter Van der Linden macht den Fall in seinem Buch "Expert C Programming":

Wir haben die Sun C-Compilerquellen analysiert, um festzustellen, wie oft der Standard-Fall-Through verwendet wurde. Das Sun ANSI C-Compiler-Frontend verfügt über 244 switch-Anweisungen, von denen jede durchschnittlich sieben Fälle aufweist. In nur 3% aller dieser Fälle tritt ein Durchfall auf.

Mit anderen Worten, das normale Schaltverhalten ist in 97% der Fälle falsch . Es ist nicht nur in einem Compiler - im Gegenteil, wo in dieser Analyse Fall Through verwendet wurde, war es häufig für Situationen, die in einem Compiler häufiger auftreten als in anderer Software, beispielsweise 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 Fällen ist so weit verbreitet, dass es sogar eine spezielle Kommentarkonvention gibt, die oben zeigt, dass "dies wirklich einer der 3% der Fälle ist, in denen ein Durchfallen gewünscht wurde".

Ich denke, es war eine gute Idee für C #, am Ende jedes Fallblocks eine explizite Sprunganweisung zu verlangen (während immer noch mehrere Fallbezeichnungen gestapelt werden können - solange es nur einen einzigen Anweisungsblock gibt). In C # kann immer noch ein Fall in einen anderen fallen - Sie müssen nur den Fall explizit machen, indem Sie mit a zum nächsten Fall springengoto .

Es ist schade, dass Java die Gelegenheit nicht genutzt hat, um von der C-Semantik abzubrechen.

In vielerlei Hinsicht ist c nur eine saubere Schnittstelle zu Standard-Assembly-Redewendungen. Beim Schreiben einer von der Sprungtabelle gesteuerten Flusssteuerung hat der Programmierer die Wahl, durch die "Steuerstruktur" zu fallen oder aus dieser herauszuspringen, und ein Herausspringen erfordert eine explizite Anweisung.

Also macht c dasselbe ...

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

Wenn Fälle so konzipiert wären, dass sie implizit brechen, könnten Sie nicht durchfallen.

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 ausgelegt wäre, dass er nach jedem Fall implizit ausbricht, hätten Sie keine Wahl. Die Schaltkastenstruktur wurde so gestaltet, dass sie flexibler ist.

Die case-Anweisungen in einer switch-Anweisung sind einfach Bezeichnungen.

Wenn Sie einen Wert einschalten, führt die switch-Anweisung im Wesentlichen ein goto aus auf das Etikett mit dem passenden Wert.

Dies bedeutet, dass die Unterbrechung erforderlich ist, um zu vermeiden, dass der Code unter dem nächsten Etikett angezeigt wird.

Was den Grund betrifft, warum es auf diese Weise implementiert wurde, ist, dass der Fall-Through-Charakter einer switch-Anweisung in einigen Szenarien nützlich sein kann. Beispielsweise:

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;

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

Stellen Sie sich das caseSchlüsselwort als gotoLabel vor und es kommt viel natürlicher.

Es verhindert die Duplizierung von Code, 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 wechseln oder nicht, gibt es sowieso keinen Overhead für Fall-Through-Fälle. Warum also nicht zulassen, da sie in bestimmten Fällen erhebliche Vorteile bieten?

Ich bin zufällig auf einen Fall gestoßen, bei dem Strukturen Werte in Vektoren zugewiesen wurden: Dies musste so erfolgen, dass der Rest der Mitglieder in verbleiben würde, wenn der Datenvektor kürzer als die Anzahl der Datenelemente in der Struktur wäre ihren Standardwert. In diesem Fall war das Weglassen breaksehr nützlich.

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

Wie viele hier angegeben haben, soll ein einzelner Codeblock für mehrere Fälle funktionieren. Dies sollte bei Ihren switch-Anweisungen häufiger vorkommen als bei dem in Ihrem Beispiel angegebenen "Codeblock pro Fall".

Wenn Sie einen Codeblock pro Fall ohne Durchfall haben, sollten Sie möglicherweise einen if-elseif-else-Block verwenden, da dies angemessener erscheint.