c# - 为什么检查这个 != null？

Question

有时我喜欢花一些时间查看 .NET 代码，看看幕后是如何实现的。我在通过 Reflector 查看 String.Equals 方法时偶然发现了这个 gem。

C#

[ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
public override bool Equals(object obj)
{
    string strB = obj as string;
    if ((strB == null) && (this != null))
    {
        return false;
    }
    return EqualsHelper(this, strB);
}

IL

.method public hidebysig virtual instance bool Equals(object obj) cil managed
{
    .custom instance void System.Runtime.ConstrainedExecution.ReliabilityContractAttribute::.ctor(valuetype System.Runtime.ConstrainedExecution.Consistency, valuetype System.Runtime.ConstrainedExecution.Cer) = { int32(3) int32(1) }
    .maxstack 2
    .locals init (
        [0] string str)
    L_0000: ldarg.1 
    L_0001: isinst string
    L_0006: stloc.0 
    L_0007: ldloc.0 
    L_0008: brtrue.s L_000f
    L_000a: ldarg.0 
    L_000b: brfalse.s L_000f
    L_000d: ldc.i4.0 
    L_000e: ret 
    L_000f: ldarg.0 
    L_0010: ldloc.0 
    L_0011: call bool System.String::EqualsHelper(string, string)
    L_0016: ret 
}

检查 this 与 null 的原因是什么？我必须假设这是有目的的，否则这可能已经被捕获并被删除了。

Answer 1

我假设您正在查看 .NET 3.5 实现？我相信 .NET 4 实现略有不同。

但是，我暗暗怀疑这是因为可以对空引用 非虚拟地调用虚拟实例方法。在 IL 中是可能的，也就是说。我会看看我是否可以生成一些调用 null.Equals(null) 的 IL。

编辑:好的，这里有一些有趣的代码:

.method private hidebysig static void  Main() cil managed
{
  .entrypoint
  // Code size       17 (0x11)
  .maxstack  2
  .locals init (string V_0)
  IL_0000:  nop
  IL_0001:  ldnull
  IL_0002:  stloc.0
  IL_0003:  ldloc.0
  IL_0004:  ldnull
  IL_0005:  call instance bool [mscorlib]System.String::Equals(string)
  IL_000a:  call void [mscorlib]System.Console::WriteLine(bool)
  IL_000f:  nop
  IL_0010:  ret
} // end of method Test::Main

我通过编译以下 C# 代码得到了这个:

using System;

class Test
{
    static void Main()
    {
        string x = null;
        Console.WriteLine(x.Equals(null));

    }
}

...然后使用 ildasm 进行反汇编和编辑。请注意这一行:

IL_0005:  call instance bool [mscorlib]System.String::Equals(string)

最初，那是 callvirt 而不是 call。

那么，当我们重新组装它时会发生什么？那么，在 .NET 4.0 中，我们得到了这个:

Unhandled Exception: System.NullReferenceException: Object
reference not set to an instance of an object.
    at Test.Main()

嗯。 .NET 2.0 怎么样？

Unhandled Exception: System.NullReferenceException: Object reference 
not set to an instance of an object.
   at System.String.EqualsHelper(String strA, String strB)
   at Test.Main()

现在更有趣了......我们显然已经成功地进入了 EqualsHelper，这是我们通常不会想到的。

足够的字符串...让我们尝试自己实现引用相等，看看我们是否可以让 null.Equals(null) 返回 true:

using System;

class Test
{
    static void Main()
    {
        Test x = null;
        Console.WriteLine(x.Equals(null));
    }

    public override int GetHashCode()
    {
        return base.GetHashCode();
    }

    public override bool Equals(object other)
    {
        return other == this;
    }
}

与之前相同的过程 - 反汇编，将 callvirt 更改为 call，重新组装，然后观察它打印 true...

请注意，尽管另一个答案引用了 this C++ question ，我们在这里更加狡猾......因为我们正在非虚拟地调用虚拟方法。通常，即使是 C++/CLI 编译器也会使用 callvirt 作为虚拟方法。换句话说，我认为在这种特殊情况下，this 为 null 的唯一方法是手动编写 IL。

---

编辑:我刚刚注意到一些事情......我实际上并没有在我们的小示例程序中调用正确的方法。这是第一种情况下的调用:

IL_0005:  call instance bool [mscorlib]System.String::Equals(string)

这是第二个电话:

IL_0005:  call instance bool [mscorlib]System.Object::Equals(object)

在第一种情况下，我打算调用System.String::Equals(object)，在第二种情况下，我打算调用 Test::Equals(object)。从中我们可以看出三点:

• 你需要小心重载。
• C# 编译器发出对虚拟方法的声明符 的调用，而不是对虚拟方法最具体的覆盖。 IIRC，VB 的工作方式相反
• object.Equals(object) 乐于比较空的“this”引用

如果您向 C# 覆盖添加一些控制台输出，您可以看到不同之处 - 它不会被调用，除非您更改 IL 以显式调用它，如下所示:

IL_0005:  call   instance bool Test::Equals(object)

所以，我们到了。空引用实例方法的乐趣和滥用。

如果到目前为止，您可能还想看看我关于 how value types can declare parameterless constructors 的博文...在伊利诺伊州。