为同一个匿名方法创建两个委托实例不相等

Question

考虑以下示例代码：

static void Main(string[] args)
{
   bool same = CreateDelegate(1) == CreateDelegate(1);
}

private static Action CreateDelegate(int x)
{
   return delegate { int z = x; };
}

您可以想象两个委托实例比较起来是相等的，就像使用良好的旧命名方法方法（new Action(MyMethod)）时一样。它们比较起来并不相等，因为 .NET Framework 为每个委托实例提供了一个隐藏的闭包实例。由于这两个委托实例各自将其 Target 属性设置为各自的隐藏实例，因此它们不会进行比较。一种可能的解决方案是为匿名方法生成的 IL 将当前实例（this 指针）存储在委托的目标中。这将允许委托进行正确的比较，并且从调试器的角度来看也有帮助，因为您将看到您的类是目标，而不是隐藏的类。

您可以在我提交给 Microsoft 的错误中阅读有关此问题的更多信息。错误报告还举例说明了我们为什么使用此功能，以及为什么我们认为应该更改它。如果您也认为这也是一个问题，请通过提供评级和验证来帮助支持它。

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx ?FeedbackID=489518

您能看出不应更改功能的任何可能原因吗？您认为这是解决问题的最佳行动方案，还是建议我采取不同的路线？

Answer 1

我不太倾向于认为这是一个“错误”。此外，您似乎假设 CLR 中的某些行为根本不存在。

这里需要理解的重要一点是，每次调用 CreateDelegate 方法时，您都会返回一个新的匿名方法（并初始化一个新的闭包类）。看来您正在熟练使用delegate关键字来在内部使用某种类型的匿名方法池。 CLR 当然不会这样做。每次调用该方法时，都会在内存中创建匿名方法的委托（与 lambda 表达式一样），并且由于相等运算符在这种情况下当然会比较引用，因此这是预期的结果返回false。

尽管您建议的行为在某些情况下可能有一些好处，但实施起来可能会相当复杂，并且更有可能导致不可预测的情况。我认为当前在每次调用时生成新的匿名方法和委托的行为是正确的，并且我怀疑这也是您在 Microsoft Connect 上得到的反馈。

如果您非常坚持要执行问题中描述的行为，则始终可以选择记忆 您的 CreateDelegate 函数，这将确保每次为相同的参数返回相同的委托。事实上，由于这非常容易实现，这可能是 Microsoft 不考虑在 CLR 中实现它的几个原因之一。

Answer 2

编辑：旧答案留给线下的历史价值...

CLR 必须计算出隐藏类可以被认为是相等的情况，同时考虑到可以对捕获的变量执行的任何操作。

在这种特殊情况下，捕获的变量 (x) 在委托内或捕获上下文中都不会更改 - 但我希望该语言不需要这种复杂的分析。语言越复杂，就越难理解。必须区分这种情况和下面的情况，其中捕获的变量的值在每次调用时都会更改 - 在那里，您调用哪个委托会产生很大的差异；他们绝不是平等的。

我认为这种已经很复杂的情况（闭包经常被误解）不试图太“聪明”并找出潜在的平等是完全明智的。

IMO，您绝对应该采取不同的路线。这些在概念上是Action的独立实例。在我看来，通过强制委托目标来伪造它是一种可怕的黑客行为。

---

问题是您正在生成的类中捕获 x 的值。这两个 x 变量是独立的，因此它们是不平等的委托。下面是一个演示独立性的示例：

using System;

class Test
{
    static void Main(string[] args)
    {
        Action first = CreateDelegate(1);
        Action second = CreateDelegate(1);
        first();
        first();
        first();
        first();
        second();
        second();
    }

    private static Action CreateDelegate(int x)
    {
        return delegate 
        { 
            Console.WriteLine(x);
            x++;
        };
    }
}

输出：

1
2
3
4
1
2

编辑： 从另一个角度来看，您的原始程序相当于：

using System;

class Test
{
    static void Main(string[] args)
    {
        bool same = CreateDelegate(1) == CreateDelegate(1);
    }

    private static Action CreateDelegate(int x)
    {
        return new NestedClass(x).ActionMethod;
    }

    private class Nested
    {
        private int x;

        internal Nested(int x)
        {
            this.x = x;
        }

        internal ActionMethod()
        {
            int z = x;
        }
    }
}

如您所知，将创建两个单独的 Nested 实例，并且它们将成为两位代表的目标。他们是不平等的，因此代表也是不平等的。

Answer 3

我不知道这个问题的 C# 具体细节，但我研究了具有相同行为的 VB.Net 等效功能。

最重要的是，这种行为是“设计使然”的，原因如下

：首先，在这种情况下，关闭是不可避免的。您在匿名方法中使用了一段本地数据，因此需要闭包来捕获状态。由于多种原因，每次调用此方法都必须创建一个新的闭包。因此，每个委托将指向该闭包上的一个实例方法。

在底层，匿名方法/表达式由代码中的 System.MulticastDelegate 派生实例表示。如果您查看此类的 Equals 方法，您会注意到 2 个重要细节

• 它是密封的，因此派生委托无法更改 equals 行为
• Equals 方法的一部分对对象进行引用比较

这使得不可能2 个 lambda 表达式附加到不同的闭包以进行相等比较。

Answer 4

我想不出在什么情况下我需要这样做。如果我需要比较委托，我总是使用命名委托，否则可能会出现这样的情况：

MyObject.MyEvent += delegate { return x + y; };

MyObject.MyEvent -= delegate { return x + y; };

这个示例不太适合演示问题，但我想象可能存在一种情况，允许这样做可能会破坏现有的代码设计时就预期这是不允许的。

我确信内部实现细节也使这成为一个坏主意，但我不确切知道匿名方法在内部是如何实现的。

Answer 5

这种行为是有道理的，因为否则匿名方法会混淆（如果它们具有相同的名称，给定相同的主体）。

您可以将代码更改为：

static void Main(){   
    bool same = CreateDelegate(1) == CreateDelegate(1);
}

static Action<int> action = (x) => { int z = x; };

private static Action<int> CreateDelegate(int x){
    return action;
}

或者，最好是，因为这是一种不好的使用方式（加上您正在比较结果，并且 Action 没有返回值...使用 Func<...> 如果您想要返回一个值）：

static void Main(){
    var action1 = action;
    var action2 = action;
    bool same = action1 == action2;  // TRUE, of course
}

static Action<int> action = (x) => { int z = x; };