给定一个简单的 switch 语句
switch (int)
{
case 1 :
{
printf("1\n");
break;
}
case 2 :
{
printf("2\n");
}
case 3 :
{
printf("3\n");
}
}
case 2 中没有 break 语句，意味着 case 3 的代码将继续执行。 这不是意外;它就是这样设计的。为什么做出这个决定？与块的自动中断语义相比，这有什么好处？理由是什么？
【问题讨论】：
标签： c language-design
许多答案似乎都集中在失败的能力上，作为需要break 声明的原因。
我认为这只是一个错误，主要是因为在设计 C 语言时，并没有太多关于如何使用这些结构的经验。
Peter Van der Linden 在他的“专家 C 编程”一书中提出了这个案例：
我们分析了 Sun C 编译器源 查看默认下降的频率 通过使用。太阳 ANSI C 编译器前端有 244 开关 语句，每个语句都有一个 平均七例。跌倒 仅发生在所有这些案例中的 3%。
也就是说，正常的开关 行为是错误 97% 的时间。 它不仅仅是在编译器中 - 在 相反，在使用跌落的地方 在这个分析中，通常是因为 更频繁发生的情况 在编译器中比在其他软件中， 例如，在编译运算符时 可以有一个或两个 操作数：
switch (operator->num_of_operands) { case 2: process_operand( operator->operand_2); /* FALLTHRU */ case 1: process_operand( operator->operand_1); break; }案例失败如此广泛 被认为是存在的缺陷 甚至是一个特别的评论约定， 如上所示，它告诉 lint “这是 真的是那 3% 的案例之一 想要跌倒。”
我认为对于 C# 来说，在每个 case 块的末尾需要一个明确的跳转语句是个好主意（同时仍然允许堆叠多个 case 标签 - 只要只有一个语句块）。在 C# 中，您仍然可以让一个案例落入另一个案例 - 您只需通过使用 goto 跳转到下一个案例来明确跌落。
Java 没有借此机会打破 C 语义，真是太糟糕了。
【讨论】：
在很多方面，c 只是标准汇编习惯用法的干净接口。在编写跳转表驱动流控制时，程序员可以选择是跳出还是跳出“控制结构”，而跳出需要显式指令。
所以，c 做同样的事情...
【讨论】：
NULL。 （在下一条评论中继续。）
NUL-terminated strings are just about the worst idea ever.
DO 循环的设计差。
显然要实现达夫的设备：
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。
这意味着break是必要的，以避免传递到下一个标签下的代码。
至于为什么以这种方式实现的原因 - 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;
【讨论】：
break。 2) 如果 case 语句的顺序发生了变化，则失败可能会导致运行错误的 case。因此，我发现 C# 的处理能力要好得多（显式 goto case 表示失败，空大小写标签除外）。
break - 最简单的方法是当您不想让 case 做任何事情但忘记添加 break 时（也许你被解释性的评论所吸引，或者被其他任务叫走）：执行将落到下面的case。 2) 鼓励goto case 鼓励非结构化的“意大利面条”编码 - 您可能会遇到意外循环 (case A: ... goto case B; case B: ... ; goto case A;)，尤其是当案例在文件中分开并且难以组合时。在 C++ 中，失败是本地化的。
允许这样的事情：
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 标签，它就自然多了。
【讨论】：
if(0) 是邪恶的，只有在目标是混淆代码时才应该使用。
当多个案例需要执行相同的代码（或按顺序执行相同的代码）时，它消除了代码重复。
由于在汇编语言级别上，它并不关心您是否在每一个之间中断，无论如何，失败案例的开销为零，所以为什么不允许它们，因为它们在某些情况下具有显着优势。
【讨论】：
我碰巧遇到了将向量中的值分配给结构的情况：必须以这样一种方式完成，即如果数据向量小于结构中数据成员的数量，则其余成员将保持其默认值。在那种情况下，省略 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);
}
【讨论】：
正如这里许多人所指定的，它允许单个代码块适用于多种情况。这应该在您的 switch 语句中比您在示例中指定的“每个案例的代码块”更常见。
如果您每个案例都有一个代码块而没有失败，也许您应该考虑使用 if-elseif-else 块，因为这似乎更合适。
【讨论】：