なぜswitch文は中断を​​必要とするように設計されたのですか？

単純なswitchステートメントがあるとします

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

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

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

ケース2にbreakステートメントがない場合、ケース3のコード内で実行が継続されることを意味します。これは偶然ではありません。そのように設計されました。なぜこの決定がなされたのですか？これには、ブロックの自動ブレークセマンティックを使用する場合と比べて、どのような利点がありますか？理論的根拠は何でしたか？

多くの回答は、陳述を要求する理由として、抜け落ちる能力に焦点を当てているようですbreak。

それは単にCが設計されたときに、これらの構成体がどのように使用されるかについてほとんど経験がなかったために、それは単に間違いであったと思います。

ピーター・ファン・デル・リンデンは、彼の著書「エキスパートCプログラミング」でそのことを述べています。

Sun Cコンパイラのソースを分析して、デフォルトのフォールスルーが使用された頻度を確認しました。Sun ANSI Cコンパイラのフロントエンドには244のswitchステートメントがあり、それぞれに平均7つのケースがあります。フォールスルーは、これらすべてのケースのわずか3％で発生します。

言い換えると、通常のスイッチ動作は97％の確率で間違っています。これはコンパイラーだけではありません-逆に、この分析でフォールスルーが使用された場合、たとえば、1つまたは2つのオペランドを持つ演算子をコンパイルするときなど、他のソフトウェアよりもコンパイラーでより頻繁に発生する状況が多かったです。 ：

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

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

ケースフォールスルーは、欠陥として広く認識されているため、上記の特別なコメント規約があり、lintに「フォールスルーが望まれたケースの3％の1つである」と伝えています。

C＃では、各caseブロックの最後に明示的なジャンプステートメントを必要とするのは良い考えだと思います（ただし、ステートメントのブロックが1つしかない限り、複数のcaseラベルをスタックできます）。C＃では、1つのケースを別のケースにフォールスルーすることができます-を使用して次のケースにジャンプして、フォールスルーを明示的にする必要がありgotoます。

JavaがCのセマンティクスから脱却する機会を得なかったのは残念です。

多くの点で、cは標準のアセンブリイディオムへのクリーンなインターフェイスです。ジャンプテーブル駆動のフロー制御を作成する場合、プログラマは「制御構造」から抜け出すか、ジャンプするかを選択でき、ジャンプアウトには明示的な命令が必要です。

したがって、cは同じことを行います...

ダフのデバイスを実装するには、明らかに：

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

ケースが暗黙のうちに壊れるように設計されている場合、フォールスルーはあり得ません。

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

スイッチがすべてのケースの後で暗黙的に発生するように設計されている場合は、それについて選択することはできません。スイッチケース構造は、より柔軟になるように設計されています。

switchステートメントのcaseステートメントは単にラベルです。

値をオンに切り替えると、switchステートメントは基本的に、一致する値を持つラベルにgotoします。

これは、次のラベルの下のコードにパススルーしないようにするために、ブレークが必要であることを意味します。

この方法で実装された理由については、switchステートメントのフォールスルーの性質が一部のシナリオで役立つ場合があります。例えば：

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;

次のようなことを許可するには：

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

caseキーワードをgotoラベルと考えてください。そうすれば、より自然なものになります。

複数のケースで同じコード（または同じコードを順番に）実行する必要がある場合、コードの重複を排除します。

アセンブリ言語レベルでは、それぞれの間で中断するかどうかは関係ないので、フォールスルーケースのオーバーヘッドはとにかくゼロなので、特定のケースで大きな利点があるため、許可しないでください。

私はたまたまベクターの値を構造体に割り当てる場合に遭遇しました：データベクトルが構造体のデータメンバーの数よりも短い場合、メンバーの残りはそのままになるような方法で行われなければなりませんでしたそれらのデフォルト値。その場合、省略breakは非常に役に立ちました。

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

ここで多くが指定しているように、1つのコードブロックが複数のケースで機能できるようにするためです。これは、例で指定する「ケースごとのコードのブロック」よりも、switchステートメントのより一般的なオカレンスになるです。

フォールスルーのないケースごとのコードブロックがある場合は、if-elseif-elseブロックを使用することを検討してください。