4

我写了一个相当复杂的方法 yield-returns IEnumerable<string>，但是当我在 Reflector 中检查编译器输出时，我不明白编译器生成的实现的特定部分IEnumerator：

void IDisposable.Dispose()
{
    switch (this.<>1__state)
    {
        case 1:
        case 2:
        case 3:
            switch (this.<>1__state) // empty switch! why?!
            {
            }
            break;

        default:
            return;
            try   // What?! AFTER return?!
            {
            }
            finally // is the try-finally block anyhow relevant?
            {
                this.<>m__Finallya();
            }
            break;
    }
    this.<>m__Finally7();
}

我猜测（或希望）Reflector 放错了外部的右大括号switch，并且它应该直接在return. 不过，我不明白为什么在案例 3 中有一个空开关，或者为什么在一个块m__Finallya中被调用。finally（正常运行和在块内运行之间是否存在语义差异finally？除了 CER，我的代码中没有。）

作为参考，这里是 IL：

.method private hidebysig newslot virtual final 
        instance void  System.IDisposable.Dispose() cil managed
{
  .override [mscorlib]System.IDisposable::Dispose
  // Code size       69 (0x45)
  .maxstack  2
  .locals init ([0] int32 CS$0$0000,
           [1] int32 CS$0$0001)
  IL_0000:  ldarg.0
  IL_0001:  ldfld      int32 FBD.TIP.Reader.MissingMessagesReader/'<GetMissingMessages>d__0'::'<>1__state'
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  ldc.i4.1
  IL_0009:  sub
  IL_000a:  switch     ( 
                        IL_001c,
                        IL_001c,
                        IL_001c)
  IL_001b:  ret
  IL_001c:  ldarg.0
  IL_001d:  ldfld      int32 FBD.TIP.Reader.MissingMessagesReader/'<GetMissingMessages>d__0'::'<>1__state'
  IL_0022:  stloc.1
  IL_0023:  ldloc.1
  IL_0024:  ldc.i4.2
  IL_0025:  sub
  IL_0026:  switch     ( 
                        IL_0035,
                        IL_0035)
  IL_0033:  br.s       IL_003e
  .try
  {
    IL_0035:  leave.s    IL_003e
  }  // end .try
  finally
  {
    IL_0037:  ldarg.0
    IL_0038:  call       instance void FBD.TIP.Reader.MissingMessagesReader/'<GetMissingMessages>d__0'::'<>m__Finallya'()
    IL_003d:  endfinally
  }  // end handler
  IL_003e:  ldarg.0
  IL_003f:  call       instance void FBD.TIP.Reader.MissingMessagesReader/'<GetMissingMessages>d__0'::'<>m__Finally7'()
  IL_0044:  ret
} // end of method '<GetMissingMessages>d__0'::System.IDisposable.Dispose
4

3 回答 3

5

你还没有展示你的原始迭代器块是什么样子，但我对反射器和编译器生成的代码的经验是，它并不总是能够完全准确地反编译，因为编译器使用了一些没有等效的 IL C＃。

我有一篇关于迭代器块实现的文章，它可能会对你有所帮助，但我不会太担心编译后的代码是什么样子。在某些情况下，C# 编译器几乎肯定会生成不必要的代码，因为这会使编译器更简单。迭代器块必须非常棘手（它可能会变得非常复杂，使用 finally 块和迭代器处理）所以我认为信任 JIT 来优化生成代码中不必要的位（如 switch/case）是合理的。

于 2009-02-17T07:48:31.217 回答
4

这只是反射器努力跟上已生成的 IL（因为迭代器块不必与“正常”C# 相关，只要它们是有效的 IL）。特别ret是在finally块之后。

于 2009-02-17T07:46:17.790 回答
1

我可以说 C# 编译器很愚蠢，（它可能有点愚蠢）。也很可能这段代码在被运行时处理时看起来非常不同（所有讨厌的垃圾都被省略了）。

无论如何，您可能熟悉状态机？当你用 C# 编写生成器（yield stuff）时，你告诉编译器发出一个匿名类型，它将这个生成器实现为状态机。这是一种很好的形式化方法，可以验证。这可能就是它看起来如此的原因。

于 2009-02-17T07:35:48.517 回答