Почему Nullable ‹T› - это структура?

Причина в том, что он не использовался как ссылочный тип. Он был разработан, чтобы действовать как тип значения, за исключением одного конкретного. Давайте посмотрим, чем отличаются типы значений и ссылочные типы.

Основное различие между типом значения и ссылочным типом заключается в том, что тип значения является самодостаточным (переменная, содержащая фактическое значение), в то время как ссылочный тип относится к другому значению.

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

Тип значения имеет концепцию равенства на основе содержащегося в нем значения, которое при желании может быть переопределено (существуют логические ограничения на то, как это переопределение может происходить *). Ссылочный тип имеет концепцию идентичности, которая не имеет смысла с типами значений (поскольку они не могут иметь прямого псевдонима, поэтому два таких значения не могут быть идентичными), которые не могут быть переопределены, что также дает значение по умолчанию для его концепции равенства. По умолчанию == имеет дело с этим равенством на основе значений, когда дело касается типов значений †, но с идентичностью, когда дело касается ссылочных типов. Кроме того, даже когда ссылочному типу дается концепция равенства, основанная на значениях, и он используется для ==, он никогда не теряет возможность сравниваться с другой ссылкой для идентификации.

Еще одно различие, связанное с этим, заключается в том, что ссылочные типы могут быть нулевыми - значение, которое относится к другому значению, допускает значение, которое не ссылается ни на какое значение, что и является нулевой ссылкой.

Кроме того, с этим связаны некоторые преимущества сохранения небольших типов значений, поскольку, будучи основанными на значении, они копируются по значению при передаче в функции.

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

Некоторые дополнительные различия между типами значений и ссылочными типами, возможно, связаны с деталями реализации. То, что тип значения в локальной переменной имеет значение, хранящееся в стеке, было аргументировано как деталь реализации; вероятно, довольно очевидный, если в вашей реализации есть стек, и, безусловно, важный в некоторых случаях, но не основной для определения. Его также часто преувеличивают (для начала, ссылочный тип в локальной переменной также имеет ссылку в стеке, во-вторых, много раз значение типа значения сохраняется в куче).

С этим связаны некоторые дополнительные преимущества в том, что типы значений являются небольшими.

Теперь Nullable<T> - это тип, который ведет себя как тип значения всеми способами, описанными выше, за исключением того, что он может принимать нулевое значение. Возможно, вопрос о хранении локальных значений в стеке не так уж и важен (это скорее деталь реализации, чем что-либо еще), но остальное зависит от того, как оно определяется.

Nullable<T> определяется как

struct Nullable<T>
{
    private bool hasValue;
    internal T value;
    /* methods and properties I won't go into here */
}

Большая часть реализации с этого момента очевидна. Требуется некоторая особая обработка, позволяющая присвоить ему значение null - обрабатываемое так, как если бы было присвоено default(Nullable<T>) - и некоторая особая обработка при упаковке, а затем следует остальное (включая то, что его можно сравнить на равенство с null).

Если бы Nullable<T> был ссылочным типом, тогда нам потребовалась бы особая обработка, чтобы все остальное могло произойти, а также особая обработка функций, позволяющих .NET помочь разработчику (например, нам потребовалась бы особая обработка, чтобы сделать это спускаются с ValueType). Я даже не уверен, возможно ли это.

* Существуют некоторые ограничения на то, как нам разрешено переопределять равенство. Комбинируя эти правила с теми, которые используются в значениях по умолчанию, обычно мы можем позволить, чтобы два значения считались равными, которые по умолчанию считались бы неравными, но редко имеет смысл рассматривать два неравных значения, которые по умолчанию считались бы равными. Исключением является случай, когда структура содержит только типы-значения, но указанные типы-значения переопределяют равенство. Это результат оптимизации и обычно считается ошибкой, а не намеренно.

† Исключение составляют типы с плавающей запятой. Из-за определения типов-значений в стандарте CLI double.NaN.Equals(double.NaN) и float.NaN.Equals(float.NaN) возвращают true. Но из-за определения NaN в ISO 60559, float.NaN == float.NaN и double.NaN == double.NaN оба возвращают false.

Отредактировано с учетом обновленного вопроса ...

Вы можете упаковывать и распаковывать объекты, если хотите использовать структуру в качестве ссылки.

Однако тип Nullable<> в основном позволяет улучшить любой тип значения с помощью дополнительного флага состояния, который сообщает, должно ли значение использоваться как null или является ли объект «действительным».

Итак, чтобы ответить на ваши вопросы:

1. Это преимущество при использовании в коллекциях или из-за разной семантики (копирование вместо ссылки)

2. Нет, это не так. CLR учитывает это при упаковке и распаковке, так что вы фактически никогда не упаковываете Nullable<> экземпляр. Упаковка Nullable<>, которая "не имеет" значения, вернет ссылку null, а при распаковке произойдет обратное.

3. Неа.

4. Опять же, это не так. Фактически общие ограничения для структуры не позволяют использовать структуры, допускающие значение NULL. Это имеет смысл из-за особого поведения упаковки / распаковки. Следовательно, если у вас есть where T: struct для ограничения универсального типа, типы, допускающие значение NULL, будут запрещены. Поскольку это ограничение также определено для типа Nullable<T>, вы не можете вкладывать их без специальной обработки, чтобы предотвратить это.

Почему бы не использовать ссылки? Я уже упоминал о важных смысловых различиях. Но помимо этого ссылочные типы используют гораздо больше памяти: каждая ссылка, особенно в 64-битных средах, использует не только память кучи для экземпляра, но также память для ссылки, информации о типе экземпляра, битов блокировки и т. Д. Таким образом, помимо семантики и различий в производительности (косвенное обращение через ссылку), вы в конечном итоге используете кратную часть памяти, используемой для самой сущности, для наиболее распространенных сущностей. И GC получает больше объектов для обработки, что еще больше ухудшает общую производительность по сравнению со структурами.

Это не изменчиво; Проверьте еще раз.

Бокс тоже другой; пустые «ящики» обнулить.

Но; он маленький (чуть больше T), неизменяемый и инкапсулирует только структуры - идеален как структура. Возможно, что еще более важно, если T действительно "значение", то и T тоже? логическое «значение».

Я закодировал MyNullable как класс. Не могу понять, почему это не может быть класс, кроме того, чтобы избежать давления на кучу памяти.

namespace ClassLibrary1

{используя NFluent;

using NUnit.Framework;

[TestFixture]
class MyNullableShould
{
    [Test]
    public void operator_equals_btw_nullable_and_value_works()
    {
        var myNullable = new MyNullable<int>(1);

        Check.That(myNullable == 1).IsEqualTo(true);
        Check.That(myNullable == 2).IsEqualTo(false);
    }

    [Test]
    public void Can_be_comparedi_with_operator_equal_equals()
    {
        var myNullable = new MyNullable<int>(1);
        var myNullable2 = new MyNullable<int>(1);

        Check.That(myNullable == myNullable2).IsTrue();
        Check.That(myNullable == myNullable2).IsTrue();

        var myNullable3 = new MyNullable<int>(2);
        Check.That(myNullable == myNullable3).IsFalse();
    }
}

} пространство имен ClassLibrary1 {using System;

public class MyNullable<T> where T : struct
{
    internal T value;

    public MyNullable(T value)
    {
        this.value = value;
        this.HasValue = true;
    }

    public bool HasValue { get; }

    public T Value
    {
        get
        {
            if (!this.HasValue) throw new Exception("Cannot grab value when has no value");
            return this.value;
        }
    }

    public static explicit operator T(MyNullable<T> value)
    {
        return value.Value;
    }

    public static implicit operator MyNullable<T>(T value)
    {
        return new MyNullable<T>(value);
    }

    public static bool operator ==(MyNullable<T> n1, MyNullable<T> n2)
    {
        if (!n1.HasValue) return !n2.HasValue;
        if (!n2.HasValue) return false;
        return Equals(n1.value, n2.value);
    }

    public static bool operator !=(MyNullable<T> n1, MyNullable<T> n2)
    {
        return !(n1 == n2);
    }

    public override bool Equals(object other)
    {
        if (!this.HasValue) return other == null;
        if (other == null) return false;
        return this.value.Equals(other);
    }

    public override int GetHashCode()
    {
        return this.HasValue ? this.value.GetHashCode() : 0;
    }

    public T GetValueOrDefault()
    {
        return this.value;
    }

    public T GetValueOrDefault(T defaultValue)
    {
        return this.HasValue ? this.value : defaultValue;
    }

    public override string ToString()
    {
        return this.HasValue ? this.value.ToString() : string.Empty;
    }
}

}