Как упоминает core, перегрузка оператора может создать впечатление, что конструктор вернул null, когда это не то, что произошло на самом деле. Авторы статьи core нашли, что они не видели, что он использовал, но на самом деле он используется в очень популярном продукте: Unity.
Это скомпилирует и зарегистрирует сообщение во время выполнения:
using UnityEngine;
public class Test:MonoBehaviour
{
void Start()
{
AudioSource as = new AudioSource();
if (as == null)
{
Debug.Log("Looks null to me.");
}
}
}
Теперь ошибка здесь моя, потому что нужно не напрямую вызывать конструктор AudioSource. Но один должен знать, что оператор == перегружен в корне дерева наследования для объектов, на которые может ссылаться Unity. Вот что говорится в руководстве Unity об операторе UnityEngine.Object ==:
Будьте осторожны при сравнении с нулем.
, например
GameObject go = new GameObject();
Debug.Log (go == null); // false
Object obj = new Object();
Debug.Log (obj == null); // true
Установка GameObject добавляет его на сцену, так что он полностью
инициализирован (! уничтожен). Создание простого UnityEngine.Object
не имеет такой семантики, поэтому ( sic ) он остается в «разрушенном» состоянии, которое
сравнивает значение true с нулем.
Хотя экземпляр GameObject инициализирует его, экземпляр объекта AudioSource - нет, поэтому сравнение с null возвращает true.
Эта необычная идиома сделана еще более скрытной благодаря тому факту, что попытки ссылаться на свойства неинициализированного объекта AudioSource будут вызывать исключения с нулевой ссылкой, которые я изначально неверно истолковал как означающие, что ссылка на объект была null, а не собственность.
Другие ответили на вопрос ОП, но я хотел бы добавить этот ответ, потому что код ОП может действительно иметь смысл, если класс Thread в нем не тот, который мы ожидаем, как Object ( и его потомки) не совсем то, что вы можете ожидать от сценария Unity (то есть на самом деле это UnityEngine.Object, а не System.Object, что приводит вас к перегруженному оператору ==, который так смутил меня) .