Pourquoi y a-t-il une différence dans la vérification de null par rapport à une valeur dans VB.NET et C #?

Dans VB.NET, cela se produit:

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

Mais en C #, cela se produit:

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");
}

Pourquoi y a-t-il une différence?

VB.NET et C # .NET sont des langages différents, construits par différentes équipes qui ont fait des hypothèses différentes sur l'utilisation; dans ce cas, la sémantique d'une comparaison NULL.

Ma préférence personnelle est pour la sémantique VB.NET, qui donne essentiellement à NULL la sémantique «je ne sais pas encore». Puis la comparaison de 5 à "Je ne sais pas encore". est naturellement "je ne sais pas encore"; c'est-à-dire NULL. Cela présente l'avantage supplémentaire de refléter le comportement de NULL dans (la plupart sinon la totalité) des bases de données SQL. C'est aussi une interprétation plus standard (que celle de C #) de la logique à trois valeurs, comme expliqué ici .

L'équipe C # a fait différentes hypothèses sur la signification de NULL, ce qui a entraîné la différence de comportement que vous montrez. Eric Lippert a écrit un blog sur la signification de NULL en C # . Per Eric Lippert: "J'ai aussi écrit sur la sémantique des nulls en VB / VBScript et JScript ici et ici ".

Dans tout environnement dans lequel des valeurs NULL sont possibles, il est important de reconnaître que la loi du milieu exclu (c'est-à-dire que A ou ~ A est tautologiquement vrai) ne peut plus être invoquée.

Mettre à jour:

A bool(par opposition à a bool?) ne peut prendre que les valeurs TRUE et FALSE. Cependant, une implémentation de langage de NULL doit décider de la façon dont NULL se propage à travers les expressions. Dans VB, les expressions 5=nullet 5<>nullLES DEUX renvoient false. En C #, des expressions comparables 5==nullet 5!=nullseule la deuxième première [mise à jour 2014-03-02 - PG] renvoie false. Cependant, dans N'IMPORTE QUEL environnement qui prend en charge NULL, il incombe au programmeur de connaître les tables de vérité et la propagation Null utilisées par ce langage.

Mettre à jour

Les articles du blog d'Eric Lippert (mentionnés dans ses commentaires ci-dessous) sur la sémantique sont maintenant à:

• 30 septembre 2003 - Beaucoup de rien

• 1 octobre 2003 - Un peu plus sur rien

Parce que x <> yrevient Nothingau lieu de true. Il n'est tout simplement pas défini car il xn'est pas défini. (similaire à SQL null).

Remarque: VB.NET Nothing<> C # null.

Vous devez également comparer la valeur de a Nullable(Of Decimal)uniquement si elle a une valeur.

Ainsi, le VB.NET ci-dessus se compare à ceci (qui semble moins incorrect):

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

La spécification du langage VB.NET :

7.1.1 Types de valeur Nullable ... Un type de valeur Nullable peut contenir les mêmes valeurs que la version non Nullable du type ainsi que la valeur Null. Ainsi, pour un type valeur Nullable, l'affectation de Nothing à une variable du type définit la valeur de la variable sur la valeur NULL, et non sur la valeur zéro du type valeur.

Par exemple:

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) '

Regardez le CIL généré (j'ai converti les deux en 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");
    }
}

Vous verrez que la comparaison dans Visual Basic renvoie Nullable <bool> (pas booléen, false ou true!). Et undefined converti en booléen est faux.

Nothingpar rapport à ce qui est toujours Nothing, pas faux dans Visual Basic (c'est le même que dans SQL).

Le problème observé ici est un cas particulier d'un problème plus général, à savoir que le nombre de définitions différentes de l'égalité qui peuvent être utiles dans au moins certaines circonstances dépasse le nombre de moyens couramment disponibles pour les exprimer. Ce problème est dans certains cas aggravé par une malheureuse croyance qu'il est déroutant d'avoir différents moyens de tester l'égalité donnant des résultats différents, et une telle confusion pourrait être évitée en faisant en sorte que les différentes formes d'égalité donnent les mêmes résultats chaque fois que possible.

En réalité, la cause fondamentale de la confusion est une croyance erronée selon laquelle les différentes formes de tests d'égalité et d'inégalité devraient produire le même résultat, même si des sémantiques différentes sont utiles dans des circonstances différentes. Par exemple, d'un point de vue arithmétique, il est utile de pouvoir Decimalcomparer les valeurs qui ne diffèrent que par le nombre de zéros à la fin. De même pour des doublevaleurs telles que zéro positif et zéro négatif. D'un autre côté, du point de vue de la mise en cache ou de l'internement, une telle sémantique peut être mortelle. Supposons, par exemple, que l'on ait un Dictionary<Decimal, String>tel qui myDict[someDecimal]devrait égaler someDecimal.ToString(). Un tel objet semblerait raisonnable si l'on avait plusieursDecimalvaleurs que l'on voulait convertir en chaîne et s'attendait à ce qu'il y ait de nombreux doublons. Malheureusement, si une telle mise en cache était utilisée pour convertir 12,3 m et 12,40 m, suivis de 12,30 m et 12,4 m, ces dernières valeurs donneraient «12,3» et «12,40» au lieu de «12,30» et «12,4».

Pour en revenir à la question à l'étude, il existe plus d'une manière sensée de comparer des objets Nullable pour l'égalité. C # part du principe que son ==opérateur doit refléter le comportement de Equals. VB.NET part du principe que son comportement doit refléter celui de certains autres langages, car quiconque souhaite le Equalscomportement peut l'utiliser Equals. Dans un certain sens, la bonne solution serait d'avoir une construction "si" à trois voies et d'exiger que si l'expression conditionnelle renvoie un résultat à trois valeurs, le code doit spécifier ce qui doit se passer dans le nullcas. Étant donné que ce n'est pas une option avec les langues telles qu'elles sont, la meilleure alternative consiste simplement à apprendre comment les différentes langues fonctionnent et à reconnaître qu'elles ne sont pas les mêmes.

Incidemment, l'opérateur "Est" de Visual Basic, qui fait défaut dans C, peut être utilisé pour tester si un objet Nullable est, en fait, null. Bien que l'on puisse raisonnablement se demander si un iftest devrait accepter a Boolean?, avoir les opérateurs de comparaison normaux retournent Boolean?plutôt que Booleanlorsqu'ils sont appelés sur des types Nullable est une fonctionnalité utile. Incidemment, dans VB.NET, si l'on tente d'utiliser l'opérateur d'égalité plutôt que Is, on obtiendra un avertissement que le résultat de la comparaison sera toujours Nothing, et on devrait l'utiliser Issi l'on veut tester si quelque chose est nul.

Peut-être que cet article vous aidera:

Si je me souviens bien, «Rien» dans VB signifie «la valeur par défaut». Pour un type valeur, c'est la valeur par défaut, pour un type référence, ce serait null. Ainsi, n'attribuer rien à une structure ne pose aucun problème.

C'est une étrange bizarrerie de VB.

Dans VB, si vous souhaitez comparer deux types Nullable, vous devez utiliser Nullable.Equals().

Dans votre exemple, cela devrait être:

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

Votre code VB est tout simplement incorrect - si vous changez le "x <> y" en "x = y", vous aurez toujours "faux" comme résultat. La manière la plus courante d'exprimer ceci pour les instances Nullable est "Not x.Equals (y)", et cela donnera le même comportement que "x! = Y" en C #.