Почему проверка это! = пустой указатель?

Полагаю, вы смотрели на реализацию .NET 3.5? Я считаю, что реализация .NET 4 немного отличается.

Однако у меня есть скрытое подозрение, что это связано с тем, что даже методы виртуального экземпляра можно вызывать не виртуально по нулевой ссылке . То есть возможно в IL. Я посмотрю, смогу ли я создать некоторый IL, который вызывал бы null.Equals (null) .

РЕДАКТИРОВАТЬ: Хорошо, вот интересный код:

.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) , чтобы вернуть истину:

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 на вызов , повторная сборка и просмотр print true ...

Обратите внимание, что хотя другой отвечает на , этот вопрос C ++ , мы здесь еще более коварны ... потому что мы вызываем виртуальный метод не виртуально. Обычно даже компилятор C ++ / CLI будет использовать callvirt для виртуального метода.Другими словами, я думаю, что в этом конкретном случае единственный способ, чтобы this было нулевым, - это написать IL вручную.

РЕДАКТИРОВАТЬ: Я только что кое-что заметил ... На самом деле я не вызывал правильный метод в ни из наших маленьких программ-примеров. Вот вызов в первом случае:

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

вот вызов во втором:

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

В первом случае I означал для вызова System.String :: Equals (object) , а во втором I имел в виду вызвать Test :: Equals (object) . Отсюда мы видим три вещи:

• Вы должны быть осторожны с перегрузками.
• Компилятор C # отправляет вызовы объявителю виртуального метода, а не самому конкретному переопределению виртуального метода. IIRC, VB работает противоположным образом
• object.Equals (object) с радостью сравнивает пустую ссылку «this»

. Если вы добавите немного вывода консоли в переопределение C #, вы увидите разницу - он не будет вызываться, если вы не измените IL для явного вызова, например:

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

Итак, вот и все. Развлечение и злоупотребление методами экземпляра для нулевых ссылок.

Если вы зашли так далеко, вам также может быть интересно посмотреть в моем блоге , как типы значений могут объявлять конструкторы без параметров ... в IL.