相同的案例条件答案

【问题标题】：Identical case condition相同的案例条件
【发布时间】：2011-10-25 05:31:37
【问题描述】：

我正在将一些 VB.NET 代码转换为 C#，因为我对它更熟悉，它可以帮助我更快地解决问题。然而，我发现这段代码在 VB.NET 中不是错误——但将其转换为 C# 会产生编译器错误。

VB.NET 代码

Select Case name
    Case "FSTF"
    .....
    Case "FSTF"
    .....
End Select

C# 转换代码

switch(name) {
    case "FSTF":
        ....;
        break;
    case "FSTF":
        ....;
        break;
}

错误是：

标签 'case "FSTF":' 已出现在此 switch 语句中。

这里的解决方案是什么——这是否意味着在 VB.NET 代码中，第二个 case 语句只是一个虚拟语句——还是第一个 case 语句是一个虚拟语句？

【问题讨论】：

你是什么意思“只是假的”？
如果我有以下陈述 int a; a=1; a=2;那么我会相信语句 a=1 是虚拟的 - 因为执行该语句没有意义；我知道，如果没有关于语句（函数调用等）的信息，就很难说……所以我的问题是先执行哪个语句，接下来执行哪个语句？
我从未听说过这个词。
dummy 来自dumb，意思是unable to speak。 dummy 然后变成了人类的模拟物（也是人体模型或木偶）。最终，任何模拟或占位符的东西都变成了假人。 Lorem ipsum 通常称为 dummy copy 或 dummy text。然后最终任何不起作用的东西。在编码中，正如@user331225 所说，这归结为 NOOP。
我认为这里真正的问题是：在 VB.NET 中，当 2 个 Case 部分具有相同的标签时会发生什么？

标签： c# vb.net switch-statement case-statement vb.net-to-c#

【解决方案1】：

我认为这样做是为了使 VB.NET 与Visual Basic 6.0 和旧版本兼容，因为这是它们的行为方式。如果 VB.NET 报告了类似 C# 的编译错误，那么将较旧的 Visual Basic 代码移植到 VB.NET 会更加困难。

奇怪的是，VB.NET 似乎不够聪明，无法消除生成的CIL 代码中的冗余情况。这导致了 C# 和 VB.NET 之间的另一个特殊差异。也就是说，当针对字符串类型like C# 时，VB.NET 不会将其策略从顺序查找更改为Dictionary 查找。这意味着使用字符串类型的 VB.NET 的 Select 构造的执行速度可能比 C# 的 switch 对应物要慢。这样做的原因（归功于 MarkJ）是因为 C# case 语句只能包含常量，而 Visual Basic case 语句可以包含表达式。

【讨论】：

C# case 语句必须是常量表达式，因此 C# 编译器可以发出缓存 Dictionary 以供以后重用的代码。 VB.Net Case 语句可以是表达式，因此 VB 编译器不能在一般情况下使用该策略。

【解决方案2】：

来自documentation for Select...Case：

如果testexpression 在多个Case 子句中匹配expressionlist 子句，则仅运行第一个匹配项之后的语句。

所以这里第二种情况实际上是多余的。就我个人而言，我更喜欢 C# 方法来突出几乎可以肯定是未被注意到的编程错误，而不是故意引入重复案例...

【讨论】：

感谢文档链接！无论如何我可以让 vb.net 为这些事情生成编译器错误？？
@user331225：我不知道。
VB.Net 允许一个“Case”语句接受一系列值（例如 6 到 10，或 >9），还允许 case 语句使用非常量表达式。虽然在静态分析显示特定情况永远不会发生时发出警告可能会有所帮助，但代码的合法性不应依赖于编译器的分析能力。
@user331225 你可以编写自己的分析器，它使用 Roslyn 编译器的 API，尽管这需要付出很大的努力。