this == null в языке C#?!

Несмотря на то, что язык C# во многих вопросах шагнул на несколько шагов вперед по сравнению со старым добрым С++, в них все еще осталось достаточно много общего. В языке C#, как и в С++, экземлярный метод класса отличается от статического благодаря неявной передаче указателя на экземпляр этого класса (a.k.a. this). Этот анахронизм хорошо спрятан от глаз, но все же он иногда проявляет себя, особенно при работе с делегатами с помощью рефлексии, когда для вызова статического метода мы передаем null, в качестве одного из параметров, а для вызова экземплярного метода, мы передаем некоторый объект, чей экземплярный метод мы хотим вызвать.

Поскольку каждый экземплярный метод все еще неявным образом получает ссылку на текущий объект (в виде неявного параметра this), то возникает вопрос, а может ли быть ситуация, когда этот самый параметр this при вызове экземплярного метода равен null, и, соответственно, насколько логично такая проверка в экземплярном методе?

// Просто тестовый класс с методом Foo
public class SomeClass
{
    public void Foo()
    {
        // Проверка this на null?!
        if (this == null)
        {
            Console.WriteLine("Ух ты! this == null!");
        }
    }
}

С первого взгяда, может показаться, что условие в методе Foo никогда не выполнится и даже некоторые инструменты (например, всеми нами любимый Решарпер) выдают предупреждение о том, что это дейсвтительно так. Если говорить о языке C#, то это, в целом, верно, и добиться выполнения этого кода без всяческих ухищрений достаточно сложно (хотя и возможно), однако это не значит, что в других языках добиться этого также сложно, как и в C#.

Итак, давайте попробуем вызвать метод Foo на «нулевом указателе» и посмотрим, что из этого выйдет:

SomeClass someClass = null;
someClass.Foo();

Как и предполагалось, мы не увидели на экране заветного «Ух ты!» вместо этого мы получим не менее заветное NRE (NullReferenceException). В целом, в таком поведении нет ничего плохого, более того, кажется вполне логичным, что мы получаем исключение при любом обращении к «пустому» экземпляру, не зависимо от того, обращается ли этот метод к this или нет.

Все дело в том, что для вызова функции в CLR существует две инструкции call и callvirt. Инструкция call используется для вызова статических, экземплярных методов или для невиртуальных вызовов виртуальных методов (например, для вызова «базовой» реализации виртуального метода); инструкция callvirt применяется для вызова экземплярных или виртуальных методов. Основным отличием этих инструкций является то, что инструкция call использует «ранее связывание», когда конкретный вызываемый метод известен на этапе компиляции; инструкция callvirt использует таблицу виртуальных функция для реализации «позднего связывания», в результате чего при вызове виртуального метода через ссылку на базовый класс будет вызван метод производного класса (да, старый добрый полиморфизм).

Еще одним, не менее важным отличием между этими двумя инструкциями является то, что при вызове инструкции callvirt CLR встраивает дополнительную проверку на null и самостоятельно генерирует NullReferenceException, а инструкция call этого не делает. Это совершенно не принципиально, когда речь идет о структурах, но когда речь заходит о ссылочных типах, разница появляется, причем существенная.

Давайте посмотрим на IL-код, который генерирует компилятор языка C# для нашего предыдущего примера:

IL_0000:  ldnull    
IL_0001:  stloc.0   
IL_0002:  ldloc.0  
IL_0003:  callvirt  PlyaingWithNRE+SomeClass.Foo

Дело все в том, что компилятор C# для вызова *всех* экземплярных методов генерирует инструкцию callvirt, даже если этот метод не является виртуальным. Если верить Эрику Гуннерсену (Eric Gunnerson) – программ-менеджеру команды Visual C# (лично у меня нет никаких оснований ему не верить), то это поведение является осознанным, хотя изначально оно и было другим. Первоначально компилятор C# (это было настолько давно, что этот язык еще даже не носил этого названия) генерировал инструкцию call для вызова невиртуальных методов и callvirt – для вызова виртуальных методов. Это приводило к тому, что NullReferenceException генерировалось не в месте «разыменовывания» указателя, а в месте обращения к полям объекта или вызове виртуального метода. Тогда разработчики компилятора посчитали такое положение вещей неприемлемым и решили, что при любом вызове метода по «нулевому указателю» пользователь должен получать исключение как можно раньше.

Теперь ответ на изначальный вопрос о том, возможно ли выполнение условия this == null, и насколько разумно добавлять проверку эту проверку в экземплярном методе, весьма прост: для выполнения этого условия достаточно вызвать метод с помощью IL инструкции call. И поскольку C# - это далеко не единственный язык программирования для платформы .Net и мы можем использовать наш класс из других языков программирования, то вполне вероятны сценарии, при которых это условие будет выполнено, и, соответственно, эта проверка окажется полезной.

Теперь давайте рассмотрим способы успешного выполнения условия в методе Foo, как на языке C# (да, я говорил, что это возможно), так и с помощью других языков программирования.

Вызов метода Foo с помощью Reflection.Emit

Этот способ нельзя назвать честным, но все же он является наиболее простым способом показать отличия между инструкциями call и callvirt, так что давайте начнем именно с него. Все, что нам в этом случае нужно – это сгенерировать динамический метод, принимающий в качестве параметра объект SomeClass и вызывающий метод Foo с помощью инструкции call:

static void CallingNullReferenceThroughReflectionEmit()
{
    // Создаем статический метод Test "динамически"
    DynamicMethod dm = new DynamicMethod("Test", typeof(void), 
        new Type[] { typeof(SomeClass) }, true);
            
    // Получаем ILGenerator для этого метода
    var il = dm.GetILGenerator();
 
    // Загружаем аргумент (в данном случае, это объект типа SomeClass)
    il.Emit(OpCodes.Ldarg_0);
            
    // Добавляем инструкцию невиртуального вызова метода Foo
    MethodInfo method = typeof(SomeClass).GetMethod("Foo");
    il.Emit(OpCodes.Call, method);
            
    // Инструкция выхода из метода
    il.Emit(OpCodes.Ret);
    SomeClass someClass = null;
    // Вызываем делегат и передаем null в качестве параметра
    dm.Invoke(null, new object[] { someClass });
}

Вызов метода Foo с помощью C++/CLI

Хотя язык C++/CLI прекрасно уживается в «управляемом» мире CLR, но он, прежде всего, остается языком C++; производительность языковых конструкций была определяющим фактором при проектировании многих его возможностей. Так что совершенно не удивительно, что некоторые свойства, характерные компилятору языка C# не характерны компилятору C++/CLI. Я не зря упоминал об изменении, внесенном разработчиками компилятора C#, когда вместо инструкций call компилятор стал генерировать инсрукции callvirt, ведь изначальное поведение компилятора C# полностью соответствует теперешнему поведению компилятора C++/CLI. В этом очень просто убедиться на очень простом примере:

SomeClass ^someClass = nullptr;
someClass->Foo();

Этот код приводит к выводу в консоль “Ух ты! this == null” именно благодаря инструкции call. Вообще, С++/CLI позволяет ряд вещей, который недоступны программистам на C# (хотя, нужно признать, подобные ситуации возникают не часто). Так, например, на C++/CLI можно легко написать код, генерирующий инструкцию call для любого произвольного виртуального метода в иерархии наследования:

// Простая иерархия наследования с классами Base и Derived
// и виртуальным методом Foo, переопределенным в наследнике
ref class Base
{
public:
    virtual void Foo()
    {
        System::Console::WriteLine("Base.Foo()");
    }
};
 
ref class Derived : public Base
{
public:
    virtual void Foo() override
    {
        System::Console::WriteLine("Derived.Foo()");
    }
};
using namespace PlayingWithNRE;
 
int main(array<System::String ^> ^args)
{
SomeClass ^someClass = nullptr;
someClass->Foo();
// ...
Base ^b = gcnew Derived();
b->Foo(); // вызываем Derived::Foo
b->Base::Foo(); //Вызываем Base::Foo

Это происходит именно благодаря тому, что во втором случае генерируется инструкция call, а не callvirt.

Вызов метода Foo из языка C#

Если вам, нам, или разработчикам компилятора, кажется, что компилятор C# *всегда* генерирует инструкцию callvirt, то на практике это происходит именно так, до тех пор, пока не приходит nikov и не убеждает компилятор в том, что он не прав.

Вот весьма простой код, который приводит к выполнению условия “this == null”:

var method = typeof(SomeClass).GetMethod("Foo");
var action = (Action)Delegate.CreateDelegate(typeof(Action), null, method);
action();

Вместо заключения

Язык C# - это отличный язык программирования, который делает нашу жизнь проще и интереснее, но это не значит, что нашим кодом не будут пользоваться разработчики на других языков программирования. И хотя проверка this на null кажется излишней даже в этом случае, практика показывает, что вы можете столкнуться с этим кодом в своей повседневной деятельности. Кроме того, всегда полезно понимать на «один уровень абстракции ниже» и знать, о чем думали разработчики языка, принимая те или иные решения.

Дополнительные ссылки

1. Eric Gunnerson. Why does C# always use callvirt?
2. Chris Brumme. Virtual and non-virtual
3. Brad Abrams. More fun with call vs callvirt