7
votes

Ces tests sont-ils des types nullables équivalents?

Voici la condition que je détectionait si nous traitons avec un type nullable: xxx

et ici le code de mon coéquipier: xxx

Nous n'avons réellement trouvé aucun cas où on retournera true et l'autre false (ou vice-versa) mais ces 2 extraits sont strictement équivalents?


9 commentaires

Si je comprends bien, les types non nullables sont une petite liste finie. Ne serait-il pas plus efficace d'identifier par leur présence?


@Jeremy: Tout struct que vous créez est un type non nullable. Je ne peux pas imaginer essayer de créer une liste d'entre eux.


Peut-être que ma question n'est pas claire mais le test doit revenir avec "int? A" et faux avec "int b"


Selon ma compréhension du code, votre coéquipier vérifie d'abord si l'élémenttype est un type générique ou non, puis si ce type générique est nullable ou non ..


@Gabe aussi, Jeremy utilise une autre interprétation pour «type nullable» que l'OP. Jeremy semble le comprendre comme "type de référence"


@Vijay: Vous avez tapé deux marques d'exclamation. Pourquoi donc?


@Vijay OUI, Cause OptionType.getGenerictypeDefinition () Si le type n'est pas générique, c'est pourquoi il y a ce premier test


@Guillaumeslashy de sorte que les chèques vont bien, voulez-vous connaître d'autres méthodes pour vérifier si un type donné est nullable ou non de ce que votre coéquipier a écrit?


Je veux juste savoir si ils sont "absolument" corrects! (Je veux dire, ils géreront tous les types nullables possibles)


5 Réponses :


4
votes

de MSDN pour NULLABLABLE.GETUDERLYDYPE Méthode :

L'argument de type du paramètre NullableType, si le paramètre NullableType est un type nullable générique fermé; Sinon, null.

Donc, oui, il est prudent d'utiliser l'ancienne version.

décompilé de GeduderlyingType: xxx


2 commentaires

Oui, mais est-ce différent du 2ème?


Voir Réponse modifiée: Il est pareil, mais légèrement plus sûr et légèrement moins efficace (sauf si le compilateur l'étouffe)



0
votes

Lorsque vous testez si un type est nullable, j'ai toujours utilisé la deuxième méthode que vous avez postée:

itemType.IsGenericType && itemType.GetGenericTypeDefinition() == typeof(Nullable<>) 


1 commentaires

Nous pensons qu'ils sont tous les deux bons, mais en même temps, nous ressentons comme dans un certain contexte, l'un d'entre eux ne fonctionnera pas ...



1
votes

Ces 2 extraits ne sont pas complètement équivalents.
Voici le boîtier de test qui renvoie une valeur différente pour chaque extraits: xxx pré>

Ainsi, la méthode nullable.getUnderlyingType plus sûr, car sa mise en œuvre incluent déjà ce cas de test: P>

public static Type GetUnderlyingType(Type nullableType) {
    if (nullableType == null) 
        throw new ArgumentNullException("nullableType");
    Type type = null;
    if ((nullableType.IsGenericType && !nullableType.IsGenericTypeDefinition)
        && (nullableType.GetGenericTypeDefinition() == typeof(Nullable<>))) {
        type = nullableType.GetGenericArguments()[0];
    }
    return type;
}


1 commentaires

Oui, faites-le de la réponse de Sehe! Thx quand même



1
votes

Le code de votre coéquipier est parfaitement bien comme indiqué dans la documentation msdn (extrait): Utilisez le code suivant pour déterminer si un objet de type représente un type nullable. N'oubliez pas que ce code revient toujours false si l'objet de type a été renvoyé à partir d'un appel à gettype. xxx

expliqué à la liaison MSDN ci-dessous: < p> http://msdn.microsoft.com/en-us/library/ MS366789.aspx

De plus, il y a une discussion similaire à ce point de vue QA:

0 commentaires


0
votes

Dotpeek montre ceci: xxx

La seule différence que je vois est si itemType est en soi générique, c'est-à-dire. typeof (liste <>) , sa volonté échouera. Et votre est légèrement plus lent car il doit en réalité trouver le type sous-jacent.


0 commentaires