'is' versus try cast avec vérification nulle

J'ai remarqué que Resharper suggère que je tourne ceci:

if (myObj.myProp is MyType)
{
   ...
}

dans ceci:

var myObjRef = myObj.myProp as MyType;
if (myObjRef != null)
{
   ...
}

Pourquoi suggérerait-il ce changement? J'ai l'habitude de Resharper suggérant des changements d'optimisation et des changements de réduction de code, mais j'ai l'impression qu'il veut prendre ma seule déclaration et la transformer en deux lignes.

Selon MSDN :

Une expression is prend la valeur true si les deux conditions suivantes sont remplies:

expression n'est pas nulle. l'expression peut être convertie en type . Autrement dit, une expression transtypée du formulaire (type)(expression)se terminera sans lever d'exception.

Suis-je mal interprété cela, ou ne isfais-je pas exactement les mêmes vérifications, juste en une seule ligne sans avoir besoin de créer explicitement une autre variable locale pour la vérification nulle?

Parce qu'il n'y a qu'un seul casting. Comparez ceci:

if (myObj.myProp is MyType) // cast #1
{
    var myObjRef = (MyType)myObj.myProp; // needs to be cast a second time
                                         // before using it as a MyType
    ...
}

pour ça:

var myObjRef = myObj.myProp as MyType; // only one cast
if (myObjRef != null)
{
    // myObjRef is already MyType and doesn't need to be cast again
    ...
}

C # 7.0 prend en charge une syntaxe plus compacte utilisant la correspondance de modèles :

if (myObj.myProp is MyType myObjRef)
{
    ...
}

La meilleure option est d'utiliser la correspondance de motifs comme celle-ci:

if (value is MyType casted){
    //Code with casted as MyType
    //value is still the same
}
//Note: casted can be used outside (after) the 'if' scope, too

Il n'y a pas encore d'informations sur ce qui se passe réellement sous la ceinture. Jetez un œil à cet exemple:

object o = "test";
if (o is string)
{
    var x = (string) o;
}

Cela se traduit par l'IL suivante:

IL_0000:  nop         
IL_0001:  ldstr       "test"
IL_0006:  stloc.0     // o
IL_0007:  ldloc.0     // o
IL_0008:  isinst      System.String
IL_000D:  ldnull      
IL_000E:  cgt.un      
IL_0010:  stloc.1     
IL_0011:  ldloc.1     
IL_0012:  brfalse.s   IL_001D
IL_0014:  nop         
IL_0015:  ldloc.0     // o
IL_0016:  castclass   System.String
IL_001B:  stloc.2     // x
IL_001C:  nop         
IL_001D:  ret   

Ce qui compte ici, ce sont les appels isinstet castclass- tous deux relativement chers. Si vous comparez cela à l'alternative, vous pouvez voir que cela ne fait qu'une isinstvérification:

object o = "test";
var oAsString = o as string;
if (oAsString != null)
{

}

IL_0000:  nop         
IL_0001:  ldstr       "test"
IL_0006:  stloc.0     // o
IL_0007:  ldloc.0     // o
IL_0008:  isinst      System.String
IL_000D:  stloc.1     // oAsString
IL_000E:  ldloc.1     // oAsString
IL_000F:  ldnull      
IL_0010:  cgt.un      
IL_0012:  stloc.2     
IL_0013:  ldloc.2     
IL_0014:  brfalse.s   IL_0018
IL_0016:  nop         
IL_0017:  nop         
IL_0018:  ret  

Il convient également de mentionner qu'un type valeur utilisera unbox.anyplutôt que castclass:

object o = 5;
if (o is int)
{
    var x = (int)o;
}

IL_0000:  nop         
IL_0001:  ldc.i4.5    
IL_0002:  box         System.Int32
IL_0007:  stloc.0     // o
IL_0008:  ldloc.0     // o
IL_0009:  isinst      System.Int32
IL_000E:  ldnull      
IL_000F:  cgt.un      
IL_0011:  stloc.1     
IL_0012:  ldloc.1     
IL_0013:  brfalse.s   IL_001E
IL_0015:  nop         
IL_0016:  ldloc.0     // o
IL_0017:  unbox.any   System.Int32
IL_001C:  stloc.2     // x
IL_001D:  nop         
IL_001E:  ret   

Notez cependant que cela ne se traduit pas nécessairement par un résultat plus rapide comme nous pouvons le voir ici . Il semble y avoir eu des améliorations depuis cette question a été posée si: moulages semblent être effectuées aussi vite qu'ils l' habitude d'être , mais aset linqsont maintenant environ 3 fois plus rapide.

Avertissement de réaffûtage:

"Type check and direct cast can be replaced with try cast and check for null"

Les deux fonctionneront, cela dépend de la façon dont votre code vous convient le plus. Dans mon cas, j'ignore simplement cet avertissement:

//1st way is n+1 times of casting
if (x is A) ((A)x).Run();
else if (x is B) ((B)x).Run();
else if (x is C) ((C)x).Run();
else if (x is D) ((D)x).Run();
//...
else if (x is N) ((N)x).Run();    
//...
else if (x is Z) ((Z)x).Run();

//2nd way is z times of casting
var a = x as Type A;
var b = x as Type B;
var c = x as Type C;
//..
var n = x as Type N;
//..
var z = x as Type Z;
if (a != null) a.Run();
elseif (b != null) b.Run();
elseif (c != null) c.Run();
...
elseif (n != null) n.Run();
...
elseif (x != null) x.Run();

Dans mon code, la deuxième manière est plus longue et moins performante.

Pour moi, cela semble dépendre des chances que ce soit de ce type ou non. Il serait certainement plus efficace de faire le casting à l'avant si l'objet est de ce type la plupart du temps. Si ce n'est qu'occasionnellement de ce type, il peut être plus optimal de vérifier d'abord avec is.

Le coût de création d'une variable locale est très négligeable par rapport au coût du contrôle de type.

La lisibilité et la portée sont généralement les facteurs les plus importants pour moi. Je ne serais pas d'accord avec ReSharper et utiliserais l'opérateur "is" pour cette seule raison; optimisez plus tard s'il s'agit d'un véritable goulot d'étranglement.

(Je suppose que vous n'utilisez myObj.myProp is MyTypequ'une seule fois dans cette fonction)

Cela devrait également suggérer un deuxième changement:

(MyType)myObj.myProp

dans

myObjRef

Cela enregistre un accès à la propriété et une distribution, par rapport au code d'origine. Mais ce n'est possible qu'après le passage isà as.

Je dirais que c'est pour créer une version fortement typée de myObj.myProp, qui est myObjRef. Cela doit ensuite être utilisé lorsque vous faites référence à cette valeur dans le bloc, plutôt que de devoir effectuer un cast.

Par exemple, ceci:

myObjRef.SomeProperty

c'est mieux que ça:

((MyType)myObj.myProp).SomeProperty