'is' rispetto a try cast con controllo null

Ho notato che Resharper suggerisce di attivare questo:

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

in questo:

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

Perché suggerirebbe questo cambiamento? Sono abituato a Resharper suggerire modifiche all'ottimizzazione e modifiche alla riduzione del codice, ma sembra che voglia prendere la mia singola affermazione e trasformarla in una doppia riga.

Secondo MSDN :

Una è espressione risulta vera se entrambe le seguenti condizioni:

l'espressione non è nulla. è possibile eseguire il cast dell'espressione al tipo . Ovvero, un'espressione cast del modulo (type)(expression)verrà completata senza generare un'eccezione.

Lo sto interpretando erroneamente o non isfaccio gli stessi identici controlli, solo in una singola riga senza la necessità di creare esplicitamente un'altra variabile locale per il controllo nullo?

Perché c'è solo un cast. Confronta questo:

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
    ...
}

a questa:

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 supporta una sintassi più compatta utilizzando la corrispondenza dei modelli :

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

L'opzione migliore è usare la corrispondenza del modello in questo modo:

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

Non ci sono ancora informazioni su ciò che accade effettivamente sotto la cintura. Dai un'occhiata a questo esempio:

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

Questo si traduce nel seguente IL:

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   

Ciò che conta qui sono le chiamate isinste castclass, entrambe relativamente costose. Se lo confronti con l'alternativa puoi vedere che fa solo un isinstcontrollo:

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  

Vale anche la pena ricordare che un tipo di valore utilizzerà unbox.anyinvece di 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   

Nota tuttavia che questo non si traduce necessariamente in un risultato più veloce come possiamo vedere qui . Sembra che ci sono stati miglioramenti poiché tale questione è stato chiesto se: calchi sembrano essere eseguito velocemente come quelli di una volta, ma ase linqora sono circa 3 volte più veloce.

Avviso di affilatura:

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

Entrambi funzioneranno, dipende da come il tuo codice ti si addice di più. Nel mio caso ignoro semplicemente quell'avvertimento:

//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();

Nel mio codice il secondo modo è più lungo e peggiore delle prestazioni.

A me questo sembra dipendere da quali sono le probabilità che sia di quel tipo o meno. Sarebbe certamente più efficiente eseguire il cast in anticipo se l'oggetto è di quel tipo la maggior parte del tempo. Se è solo occasionalmente di quel tipo, potrebbe essere più ottimale controllare prima con is.

Il costo della creazione di una variabile locale è molto trascurabile rispetto al costo del controllo del tipo.

La leggibilità e la portata sono i fattori più importanti per me in genere. Non sarei d'accordo con ReSharper e utilizzerei l'operatore "is" solo per questo motivo; ottimizzare in seguito se si tratta di un vero collo di bottiglia.

(Presumo che tu stia usando solo myObj.myProp is MyTypeuna volta in questa funzione)

Dovrebbe suggerire anche una seconda modifica:

(MyType)myObj.myProp

in

myObjRef

Ciò consente di risparmiare un accesso alla proprietà e un cast, rispetto al codice originale. Ma è possibile solo dopo il passaggio isa as.

Direi che questo è per creare una versione fortemente tipizzata di myObj.myProp, che è myObjRef. Questo dovrebbe quindi essere utilizzato quando si fa riferimento a questo valore nel blocco, invece di dover eseguire un cast.

Ad esempio, questo:

myObjRef.SomeProperty

è meglio di questo:

((MyType)myObj.myProp).SomeProperty