Transmitir vs usar la palabra clave 'as' en el CLR

Al programar interfaces, descubrí que estoy haciendo muchas conversiones o conversión de tipo de objeto.

¿Hay alguna diferencia entre estos dos métodos de conversión? Si es así, ¿hay una diferencia de costo o cómo afecta esto a mi programa?

public interface IMyInterface
{
    void AMethod();
}

public class MyClass : IMyInterface
{
    public void AMethod()
    {
       //Do work
    }

    // Other helper methods....
}

public class Implementation
{
    IMyInterface _MyObj;
    MyClass _myCls1;
    MyClass _myCls2;

    public Implementation()
    {
        _MyObj = new MyClass();

        // What is the difference here:
        _myCls1 = (MyClass)_MyObj;
        _myCls2 = (_MyObj as MyClass);
    }
}

Además, ¿cuál es "en general" el método preferido?

La respuesta debajo de la línea fue escrita en 2008.

C # 7 introdujo la coincidencia de patrones, que ha reemplazado en gran medida al asoperador, como ahora puede escribir:

if (randomObject is TargetType tt)
{
    // Use tt here
}

Tenga en cuenta que tttodavía está dentro del alcance después de esto, pero no está definitivamente asignado. ( Definitivamente está asignado dentro del ifcuerpo). Eso es un poco molesto en algunos casos, por lo que si realmente te importa introducir la menor cantidad de variables posibles en cada ámbito, es posible que aún quieras usar isseguido de un reparto.

No creo que ninguna de las respuestas hasta ahora (en el momento de comenzar esta respuesta) haya explicado realmente dónde vale la pena usar cuál.

• No hagas esto:

  // Bad code - checks type twice for no reason
  if (randomObject is TargetType)
  {
      TargetType foo = (TargetType) randomObject;
      // Do something with foo
  }

  Esto no solo está comprobando dos veces, sino que puede estar comprobando cosas diferentes, si randomObjectes un campo en lugar de una variable local. Es posible que el "si" pase pero luego el lanzamiento falle, si otro hilo cambia el valor de randomObjectentre los dos.

• Si randomObjectrealmente debería ser una instancia de TargetType, es decir, si no lo es, eso significa que hay un error, entonces lanzar es la solución correcta. Eso arroja una excepción de inmediato, lo que significa que no se realiza más trabajo bajo suposiciones incorrectas, y la excepción muestra correctamente el tipo de error.

  // This will throw an exception if randomObject is non-null and
  // refers to an object of an incompatible type. The cast is
  // the best code if that's the behaviour you want.
  TargetType convertedRandomObject = (TargetType) randomObject;

• Si randomObject podría ser una instancia de TargetTypey TargetTypees un tipo de referencia, utilice un código como este:

  TargetType convertedRandomObject = randomObject as TargetType;
  if (convertedRandomObject != null)
  {
      // Do stuff with convertedRandomObject
  }

• Si randomObject podría ser una instancia de TargetTypey TargetTypees un tipo de valor, entonces no podemos usarlo asconsigo TargetTypemismo, pero podemos usar un tipo anulable:

  TargetType? convertedRandomObject = randomObject as TargetType?;
  if (convertedRandomObject != null)
  {
      // Do stuff with convertedRandomObject.Value
  }

  (Nota: actualmente esto es en realidad más lento que el reparto + . Creo que es más elegante y consistente, pero ahí vamos).

• Si realmente no necesita el valor convertido, pero solo necesita saber si es una instancia de TargetType, entonces el isoperador es su amigo. En este caso, no importa si TargetType es un tipo de referencia o un tipo de valor.

• Puede haber otros casos que involucren genéricos donde issea ​​útil (porque es posible que no sepa si T es un tipo de referencia o no, por lo que no puede usar como), pero son relativamente oscuros.

• Es casi seguro que lo he usado antes ispara el caso del tipo de valor, sin haber pensado en usar un tipo anulable y asjuntos :)

EDITAR: tenga en cuenta que ninguno de los anteriores habla sobre el rendimiento, excepto el caso del tipo de valor, donde he notado que unboxing a un tipo de valor anulable es en realidad más lento, pero consistente.

De acuerdo con la respuesta de naasking, is-and-cast o is-and-as son tan rápidos como el chequeo nulo con los JIT modernos, como se muestra en el siguiente código:

using System;
using System.Diagnostics;
using System.Linq;

class Test
{
    const int Size = 30000000;

    static void Main()
    {
        object[] values = new object[Size];
        for (int i = 0; i < Size - 2; i += 3)
        {
            values[i] = null;
            values[i + 1] = "x";
            values[i + 2] = new object();
        }
        FindLengthWithIsAndCast(values);
        FindLengthWithIsAndAs(values);
        FindLengthWithAsAndNullCheck(values);
    }

    static void FindLengthWithIsAndCast(object[] values)        
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            if (o is string)
            {
                string a = (string) o;
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("Is and Cast: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithIsAndAs(object[] values)        
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            if (o is string)
            {
                string a = o as string;
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("Is and As: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithAsAndNullCheck(object[] values)        
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            string a = o as string;
            if (a != null)
            {
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("As and null check: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }
}

En mi computadora portátil, todo esto se ejecuta en aproximadamente 60 ms. Dos cosas a tener en cuenta:

• No hay diferencia significativa entre ellos. (De hecho, hay situaciones en las que la verificación as-plus-null definitivamente es más lenta. El código anterior en realidad facilita la verificación de tipo porque es para una clase sellada; si está buscando una interfaz, la balanza se inclina ligeramente a favor de as-plus-null-check.)
• Todos son increíblemente rápidos. Esto simplemente no será el cuello de botella en su código a menos que realmente no vaya a hacer nada con los valores después.

Así que no nos preocupemos por el rendimiento. Preocupémonos por la corrección y la consistencia.

Sostengo que is-and-cast (o is-and-as) no son seguros cuando se trata de variables, ya que el tipo del valor al que se refiere puede cambiar debido a otro hilo entre la prueba y el elenco. Esa sería una situación bastante rara, pero prefiero tener una convención que pueda usar de manera consistente.

También sostengo que el cheque nulo como entonces da una mejor separación de las preocupaciones. Tenemos una declaración que intenta una conversión, y luego una declaración que usa el resultado. Is-and-cast o is-and-as realiza una prueba y luego otro intento de convertir el valor.

Para decirlo de otra manera, ¿alguien escribiría alguna vez :

int value;
if (int.TryParse(text, out value))
{
    value = int.Parse(text);
    // Use value
}

Eso es algo de lo que está haciendo el reparto, aunque obviamente de una manera bastante más barata.

"as" devolverá NULL si no es posible lanzarlo.

lanzar antes generará una excepción.

Para el rendimiento, generar una excepción suele ser más costoso en el tiempo.

Aquí hay otra respuesta, con alguna comparación IL. Considera la clase:

public class MyClass
{
    public static void Main()
    {
        // Call the 2 methods
    }

    public void DirectCast(Object obj)
    {
        if ( obj is MyClass)
        { 
            MyClass myclass = (MyClass) obj; 
            Console.WriteLine(obj);
        } 
    } 


    public void UsesAs(object obj) 
    { 
        MyClass myclass = obj as MyClass; 
        if (myclass != null) 
        { 
            Console.WriteLine(obj);
        } 
    }
}

Ahora mire la IL que produce cada método. Incluso si los códigos operativos no significan nada para usted, puede ver una diferencia importante: isinst se llama seguido de castclass en el método DirectCast. Entonces, dos llamadas en lugar de una básicamente.

.method public hidebysig instance void  DirectCast(object obj) cil managed
{
  // Code size       22 (0x16)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  isinst     MyClass
  IL_0006:  brfalse.s  IL_0015
  IL_0008:  ldarg.1
  IL_0009:  castclass  MyClass
  IL_000e:  pop
  IL_000f:  ldarg.1
  IL_0010:  call       void [mscorlib]System.Console::WriteLine(object)
  IL_0015:  ret
} // end of method MyClass::DirectCast

.method public hidebysig instance void  UsesAs(object obj) cil managed
{
  // Code size       17 (0x11)
  .maxstack  1
  .locals init (class MyClass V_0)
  IL_0000:  ldarg.1
  IL_0001:  isinst     MyClass
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  brfalse.s  IL_0010
  IL_000a:  ldarg.1
  IL_000b:  call       void [mscorlib]System.Console::WriteLine(object)
  IL_0010:  ret
} // end of method MyClass::UsesAs

La palabra clave isinst versus la clase de cast

Esta publicación de blog tiene una comparación decente entre las dos formas de hacerlo. Su resumen es:

• En una comparación directa, isinst es más rápido que castclass (aunque solo ligeramente)
• Al tener que realizar verificaciones para asegurar que la conversión fue exitosa, isinst fue significativamente más rápido que castclass
• No se debe usar una combinación de isinst y castclass, ya que esto fue mucho más lento que la conversión "segura" más rápida (más del 12% más lenta)

Personalmente siempre uso As, porque es fácil de leer y lo recomienda el equipo de desarrollo de .NET (o Jeffrey Richter de todos modos)

Una de las diferencias más sutiles entre los dos es que la palabra clave "as" no se puede usar para emitir cuando un operador de conversión está involucrado:

public class Foo
{
    public string Value;

    public static explicit operator string(Foo f)
    {
        return f.Value;
    }

}

public class Example
{
    public void Convert()
    {
        var f = new Foo();
        f.Value = "abc";

        string cast = (string)f;
        string tryCast = f as string;
    }
}

Esto no se compilará (aunque creo que lo hizo en versiones anteriores) en la última línea, ya que las palabras clave "como" no tienen en cuenta los operadores de conversión. Sin string cast = (string)f;embargo, la línea funciona bien.

como nunca arroja una excepción si no puede realizar la conversión devolviendo nulo en su lugar ( ya que opera solo en tipos de referencia). Entonces, usar as es básicamente equivalente a

_myCls2 = _myObj is MyClass ? (MyClass)_myObj : null;

Los lanzamientos de estilo C, por otro lado, arrojan una excepción cuando no es posible la conversión.

No es realmente una respuesta a su pregunta, pero creo que es un punto relacionado importante.

Si está programando para una interfaz, no debería necesitar emitir. Esperemos que estos moldes sean muy raros. Si no, es probable que deba repensar algunas de sus interfaces.

Ignore el consejo de Jon Skeet, re: evite el patrón de prueba y reparto, es decir:

if (randomObject is TargetType)
{
    TargetType foo = randomObject as TargetType;
    // Do something with foo
}

La idea de que esto cuesta más que un reparto y una prueba nula es un MITO :

TargetType convertedRandomObject = randomObject as TargetType;
if (convertedRandomObject != null)
{
    // Do stuff with convertedRandomObject
}

Es una microoptimización que no funciona. Hice algunas pruebas reales , y test-and-cast es en realidad más rápido que la comparación de lanzamiento y nulo, y también es más seguro porque no tienes la posibilidad de tener una referencia nula en el ámbito fuera del if debería el lanzamiento fallar.

Si desea una razón por la cual la prueba y el lanzamiento es más rápida, o al menos no más lenta, hay una razón simple y compleja.

Simple: incluso los compiladores ingenuos fusionarán dos operaciones similares, como test-and-cast, en una sola prueba y rama. cast-and-null-test puede forzar dos pruebas y una rama, una para la prueba de tipo y conversión a nulo en caso de falla, una para la verificación nula en sí. Como mínimo, ambos se optimizarán para una sola prueba y ramificación, por lo que test-and-cast no sería ni más lento ni más rápido que cast-and-null-test.

Complejo: por qué test-and-cast es más rápido: cast-and-null-test introduce otra variable en el ámbito externo que el compilador debe rastrear para determinar la vida, y es posible que no pueda optimizar esa variable dependiendo de cuán complejo sea su control. el flujo es Por el contrario, test-and-cast introduce una nueva variable solo en un ámbito delimitado para que el compilador sepa que la variable está muerta después de que el ámbito finalice, y así puede optimizar mejor la asignación de registros.

Así que por favor, POR FAVOR, deje que este consejo de "probar y anular prueba sea mejor que probar y emitir" muera. POR FAVOR. test-and-cast es más seguro y más rápido.

Si el reparto falla, la palabra clave 'as' no arroja una excepción; establece la variable en nulo (o en su valor predeterminado para los tipos de valor) en su lugar.

Esta no es una respuesta a la pregunta, sino un comentario al ejemplo de código de la pregunta:

Por lo general, no debería tener que lanzar un objeto desde, por ejemplo, IMyInterface a MyClass. Lo mejor de las interfaces es que si toma un objeto como entrada que implementa una interfaz, no tiene que preocuparse de qué tipo de objeto está obteniendo.

Si lanza IMyInterface a MyClass, entonces ya asume que obtiene un objeto de tipo MyClass y no tiene sentido usar IMyInterface, porque si alimenta su código con otras clases que implementan IMyInterface, rompería su código ...

Ahora, mi consejo: si sus interfaces están bien diseñadas, puede evitar muchos tipos de letra.

El asoperador solo se puede usar en tipos de referencia, no se puede sobrecargar y volverá nullsi la operación falla. Nunca arrojará una excepción.

La transmisión se puede usar en cualquier tipo compatible, se puede sobrecargar y generará una excepción si la operación falla.

La elección de cuál usar depende de las circunstancias. Principalmente, se trata de si desea lanzar una excepción en una conversión fallida.

Mi respuesta es solo sobre la velocidad en los casos en que no verificamos el tipo y no verificamos los valores nulos después del lanzamiento. Agregué dos pruebas adicionales al código de Jon Skeet:

using System;
using System.Diagnostics;

class Test
{
    const int Size = 30000000;

    static void Main()
    {
        object[] values = new object[Size];

        for (int i = 0; i < Size; i++)
        {
            values[i] = "x";
        }
        FindLengthWithIsAndCast(values);
        FindLengthWithIsAndAs(values);
        FindLengthWithAsAndNullCheck(values);

        FindLengthWithCast(values);
        FindLengthWithAs(values);

        Console.ReadLine();
    }

    static void FindLengthWithIsAndCast(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            if (o is string)
            {
                string a = (string)o;
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("Is and Cast: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithIsAndAs(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            if (o is string)
            {
                string a = o as string;
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("Is and As: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithAsAndNullCheck(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            string a = o as string;
            if (a != null)
            {
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("As and null check: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }
    static void FindLengthWithCast(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            string a = (string)o;
            len += a.Length;
        }
        sw.Stop();
        Console.WriteLine("Cast: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithAs(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            string a = o as string;
            len += a.Length;
        }
        sw.Stop();
        Console.WriteLine("As: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }
}

Resultado:

Is and Cast: 30000000 : 88
Is and As: 30000000 : 93
As and null check: 30000000 : 56
Cast: 30000000 : 66
As: 30000000 : 46

No intentes concentrarte en la velocidad (como lo hice) porque todo esto es muy, muy rápido.

Además de todo lo que ya se expuso aquí, acabo de encontrar una diferencia práctica que creo que vale la pena señalar, entre el casting explícito

var x = (T) ...

versus usar el asoperador.

Aquí está el ejemplo:

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(GenericCaster<string>(12345));
        Console.WriteLine(GenericCaster<object>(new { a = 100, b = "string" }) ?? "null");
        Console.WriteLine(GenericCaster<double>(20.4));

        //prints:
        //12345
        //null
        //20.4

        Console.WriteLine(GenericCaster2<string>(12345));
        Console.WriteLine(GenericCaster2<object>(new { a = 100, b = "string" }) ?? "null");

        //will not compile -> 20.4 does not comply due to the type constraint "T : class"
        //Console.WriteLine(GenericCaster2<double>(20.4));
    }

    static T GenericCaster<T>(object value, T defaultValue = default(T))
    {
        T castedValue;
        try
        {
            castedValue = (T) Convert.ChangeType(value, typeof(T));
        }
        catch (Exception)
        {
            castedValue = defaultValue;
        }

        return castedValue;
    }

    static T GenericCaster2<T>(object value, T defaultValue = default(T)) where T : class
    {
        T castedValue;
        try
        {
            castedValue = Convert.ChangeType(value, typeof(T)) as T;
        }
        catch (Exception)
        {
            castedValue = defaultValue;
        }

        return castedValue;
    }
}

En pocas palabras : GenericCaster2 no funcionará con tipos de estructura. GenericCaster lo hará.

Si usa los PIA de Office dirigidos a .NET Framework 4.X, debe usar la palabra clave como , de lo contrario, no se compilará.

Microsoft.Office.Interop.Outlook.Application o = new Microsoft.Office.Interop.Outlook.Application();
Microsoft.Office.Interop.Outlook.MailItem m = o.CreateItem(Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as Microsoft.Office.Interop.Outlook.MailItem;

Sin embargo, la transmisión está bien cuando se dirige a .NET 2.0:

Microsoft.Office.Interop.Outlook.MailItem m = (Microsoft.Office.Interop.Outlook.MailItem)o.CreateItem(Microsoft.Office.Interop.Outlook.OlItemType.olMailItem);

Al apuntar a .NET 4.X los errores son:

error CS0656: Falta compilador miembro requerido 'Microsoft.CSharp.RuntimeBinder.Binder.Convert'

error CS0656: falta compilador miembro requerido 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'

La aspalabra clave funciona igual que una conversión explícita entre tipos de referencia compatibles con la gran diferencia de que no genera una excepción si la conversión falla. Más bien, produce un valor nulo en la variable objetivo. Dado que las Excepciones son muy caras en términos de rendimiento, se considera un método de lanzamiento mucho mejor.

Lo que elija depende en gran medida de lo que requiera. Prefiero casting explícito

IMyInterface = (IMyInterface)someobj;

porque si el objeto debería ser del tipo IMyInterface y no lo es, definitivamente es un problema. Es mejor obtener el error lo antes posible porque se solucionará el error exacto en lugar de corregir su efecto secundario.

Pero si maneja métodos que aceptan objectcomo parámetro, entonces debe verificar su tipo exacto antes de ejecutar cualquier código. En tal caso assería útil para que puedas evitarlo InvalidCastException.

Depende, ¿desea verificar si es nulo después de usar "como" o prefiere que su aplicación arroje una excepción?

Mi regla general es que si siempre espero que la variable sea del tipo que estoy esperando en el momento en que quiero, uso un yeso. Si es posible que la variable no se convierta en lo que quiero y estoy preparado para manejar los valores nulos de usar as, usaré as.

Echa un vistazo a estos enlaces:

• http://gen5.info/q/2008/06/13/prefix-casting-versus-as-casting-in-c/
• http://www.codeproject.com/Articles/8052/Type-casting-impact-over-execution-performance-in

Te muestran algunos detalles y pruebas de rendimiento.

El problema del OP se limita a una situación de lanzamiento específica. El título cubre muchas más situaciones.
Aquí hay una descripción general de todas las situaciones de casting relevantes en las que actualmente puedo pensar:

private class CBase
{
}

private class CInherited : CBase
{
}

private enum EnumTest
{
  zero,
  one,
  two
}

private static void Main (string[] args)
{
  //########## classes ##########
  // object creation, implicit cast to object
  object oBase = new CBase ();
  object oInherited = new CInherited ();

  CBase oBase2 = null;
  CInherited oInherited2 = null;
  bool bCanCast = false;

  // explicit cast using "()"
  oBase2 = (CBase)oBase;    // works
  oBase2 = (CBase)oInherited;    // works
  //oInherited2 = (CInherited)oBase;   System.InvalidCastException
  oInherited2 = (CInherited)oInherited;    // works

  // explicit cast using "as"
  oBase2 = oBase as CBase;
  oBase2 = oInherited as CBase;
  oInherited2 = oBase as CInherited;  // returns null, equals C++/CLI "dynamic_cast"
  oInherited2 = oInherited as CInherited;

  // testing with Type.IsAssignableFrom(), results (of course) equal the results of the cast operations
  bCanCast = typeof (CBase).IsAssignableFrom (oBase.GetType ());    // true
  bCanCast = typeof (CBase).IsAssignableFrom (oInherited.GetType ());    // true
  bCanCast = typeof (CInherited).IsAssignableFrom (oBase.GetType ());    // false
  bCanCast = typeof (CInherited).IsAssignableFrom (oInherited.GetType ());    // true

  //########## value types ##########
  int iValue = 2;
  double dValue = 1.1;
  EnumTest enValue = EnumTest.two;

  // implicit cast, explicit cast using "()"
  int iValue2 = iValue;   // no cast
  double dValue2 = iValue;  // implicit conversion
  EnumTest enValue2 = (EnumTest)iValue;  // conversion by explicit cast. underlying type of EnumTest is int, but explicit cast needed (error CS0266: Cannot implicitly convert type 'int' to 'test01.Program.EnumTest')

  iValue2 = (int)dValue;   // conversion by explicit cast. implicit cast not possible (error CS0266: Cannot implicitly convert type 'double' to 'int')
  dValue2 = dValue;
  enValue2 = (EnumTest)dValue;  // underlying type is int, so "1.1" beomces "1" and then "one"

  iValue2 = (int)enValue;
  dValue2 = (double)enValue;
  enValue2 = enValue;   // no cast

  // explicit cast using "as"
  // iValue2 = iValue as int;   error CS0077: The as operator must be used with a reference type or nullable type
}