Почему существует разница в проверке нуля на значение в VB.NET и C #?

В VB.NET это происходит:

Dim x As System.Nullable(Of Decimal) = Nothing
Dim y As System.Nullable(Of Decimal) = Nothing

y = 5
If x <> y Then
    Console.WriteLine("true")
Else
    Console.WriteLine("false") '' <-- I got this. Why?
End If

Но в C # такое бывает:

decimal? x = default(decimal?);
decimal? y = default(decimal?);

y = 5;
if (x != y)
{
    Debug.WriteLine("true"); // <-- I got this -- I'm with you, C# :)
}
else
{
    Debug.WriteLine("false");
}

Почему есть разница?

VB.NET и C # .NET - это разные языки, созданные разными командами, которые сделали разные предположения об использовании; в этом случае семантика сравнения NULL.

Лично я предпочитаю семантику VB.NET, которая, по сути, дает NULL семантику «Я еще не знаю». Затем сравнение 5 с «Еще не знаю». естественно «я еще не знаю»; т.е. NULL. Это имеет дополнительное преимущество в виде зеркального отображения поведения NULL в (в большинстве, если не во всех) базах данных SQL. Это также более стандартная (чем в C #) интерпретация трехзначной логики, как объясняется здесь .

Команда C # сделала разные предположения о том, что означает NULL, что привело к разнице в поведении, которую вы показываете. Эрик Липперт написал в блоге о значении NULL в C # . Пер Эрик Липперт: «Я также писал о семантике пустых значений в VB / VBScript и JScript здесь и здесь ».

В любой среде, в которой возможны значения NULL, важно признать, что на закон исключенного среднего (т. Е. Что A или ~ A тавтологически истинны) больше нельзя полагаться.

Обновить:

A bool(в отличие от a bool?) может принимать только значения TRUE и FALSE. Однако языковая реализация NULL должна решить, как NULL распространяется через выражения. В VB выражения 5=nullи 5<>nullОБА возвращают ложь. В C #, из сопоставимых выражений 5==nullи 5!=nullтолько второй первый [обновление 2014-03-02 - PG] возвращает ложь. Однако в ЛЮБОЙ среде, поддерживающей значение null, программист должен знать таблицы истинности и распространение нуля, используемые этим языком.

Обновить

Статьи в блоге Эрика Липперта (упомянутые в его комментариях ниже) по семантике сейчас находятся по адресу:

• 30 сентября 2003 г. - A Whole Lot of Nothing

• 1 октября 2003 г. - Еще немного ни о чем

Потому что x <> yвозвращает Nothingвместо true. Он просто не определен, поскольку xне определен. (аналогично SQL null).

Примечание: VB.NET Nothing<> C # null.

Вы также должны сравнивать значение a, Nullable(Of Decimal)только если оно имеет значение.

Таким образом, VB.NET выше сравнивается примерно с этим (что выглядит менее некорректным):

If x.HasValue AndAlso y.HasValue AndAlso x <> y Then
    Console.WriteLine("true")
Else
    Console.WriteLine("false")  
End If

Спецификация языка VB.NET :

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

Например:

Dim x As Integer = Nothing
Dim y As Integer? = Nothing

Console.WriteLine(x) ' Prints zero '
Console.WriteLine(y) ' Prints nothing (because the value of y is the null value) '

Посмотрите на сгенерированный CIL (я преобразовал оба на C #):

C #:

private static void Main(string[] args)
{
    decimal? x = null;
    decimal? y = null;
    y = 5M;
    decimal? CS$0$0000 = x;
    decimal? CS$0$0001 = y;
    if ((CS$0$0000.GetValueOrDefault() != CS$0$0001.GetValueOrDefault()) ||
        (CS$0$0000.HasValue != CS$0$0001.HasValue))
    {
        Console.WriteLine("true");
    }
    else
    {
        Console.WriteLine("false");
    }
}

Visual Basic:

[STAThread]
public static void Main()
{
    decimal? x = null;
    decimal? y = null;
    y = 5M;
    bool? VB$LW$t_struct$S3 = new bool?(decimal.Compare(x.GetValueOrDefault(), y.GetValueOrDefault()) != 0);
    bool? VB$LW$t_struct$S1 = (x.HasValue & y.HasValue) ? VB$LW$t_struct$S3 : null;
    if (VB$LW$t_struct$S1.GetValueOrDefault())
    {
        Console.WriteLine("true");
    }
    else
    {
        Console.WriteLine("false");
    }
}

Вы увидите, что сравнение в Visual Basic возвращает значение Nullable <bool> (не bool, false или true!). А undefined, преобразованный в bool, является ложным.

Nothingпо сравнению с тем, что всегда Nothing, а не ложью в Visual Basic (это то же самое, что и в SQL).

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

На самом деле фундаментальной причиной путаницы является ошибочное убеждение, что следует ожидать, что разные формы проверки на равенство и неравенство дадут один и тот же результат, несмотря на тот факт, что разная семантика полезна в разных обстоятельствах. Например, с точки зрения арифметики полезно иметь возможность Decimalсравнивать те , которые отличаются только количеством конечных нулей, как равные. То же самое для doubleтаких значений, как положительный ноль и отрицательный ноль. С другой стороны, с точки зрения кэширования или интернирования такая семантика может быть смертельной. Допустим, например, у одного есть Dictionary<Decimal, String>такой, на который myDict[someDecimal]должно равняться someDecimal.ToString(). Такой объект казался бы разумным, если бы у него было многоDecimalзначения, которые нужно было преобразовать в строку и ожидалось, что будет много дубликатов. К сожалению, если использовать такое кэширование для преобразования 12,3 м и 12,40 м, а затем 12,30 м и 12,4 м, последние значения дадут «12,3» и «12,40» вместо «12,30» и «12,4».

Возвращаясь к рассматриваемому вопросу, существует более одного разумного способа сравнения обнуляемых объектов на предмет равенства. C # придерживается точки зрения, что его ==оператор должен отражать поведение Equals. VB.NET придерживается точки зрения, что его поведение должно отражать поведение некоторых других языков, поскольку любой, кто хочет, Equalsможет использовать его Equals. В некотором смысле правильным решением было бы иметь трехстороннюю конструкцию «if» и требовать, чтобы, если условное выражение возвращает трехзначный результат, код должен указывать, что должно происходить в nullслучае. Поскольку это не вариант с языками как они есть, следующая лучшая альтернатива - просто изучить, как работают разные языки, и признать, что они не совпадают.

Между прочим, оператор «Is» в Visual Basic, которого нет в C, можно использовать для проверки того, действительно ли объект, допускающий значение NULL, равен NULL. Хотя можно резонно задаться вопросом, ifдолжен ли тест принимать a Boolean?, наличие обычных операторов сравнения, возвращаемых Boolean?вместо того, чтобы Booleanвызывать их для типов, допускающих значение NULL, является полезной функцией. Между прочим, в VB.NET, если кто-то попытается использовать оператор равенства, а не Is, вы получите предупреждение о том, что результат сравнения всегда будет Nothing, и его следует использовать, Isесли кто-то хочет проверить, является ли что-то нулевым.

Может быть этот пост вам поможет:

Если я правильно помню, «Ничего» в VB означает «значение по умолчанию». Для типа значения это значение по умолчанию, для ссылочного типа это будет null. Таким образом, ничего не присваивать структуре - это вообще не проблема.

Это определенная странность VB.

В VB, если вы хотите сравнить два типа, допускающие значение NULL, вы должны использовать Nullable.Equals().

В вашем примере это должно быть:

Dim x As System.Nullable(Of Decimal) = Nothing
Dim y As System.Nullable(Of Decimal) = Nothing

y = 5
If Not Nullable.Equals(x, y) Then
    Console.WriteLine("true")
Else
    Console.WriteLine("false")
End If

Ваш код VB просто неверен - если вы измените «x <> y» на «x = y», в результате вы все равно получите «false». Наиболее распространенный способ выражения this для экземпляров, допускающих значение NULL, - «Not x.Equals (y)», и это приведет к тому же поведению, что и «x! = Y» в C #.