¿Por qué el casting proporciona CS0030, mientras que "as" funciona?

Question

Supongamos que tengo un método genérico:

T Foo(T x) { 
    return x; 
} 

Hasta aquí todo bien. Pero quiero hacer algo especial si es un Hashtable. (Sé que esto es un ejemplo completamente artificial. Foo() no es un método muy emocionante, ya sea. El juego.)

if (typeof(T) == typeof(Hashtable)) { 
    var h = ((Hashtable)x); // CS0030: Cannot convert type 'T' to 'System.Collections.Hashtable' 
} 

Darn. Para ser justos, no puedo decir si esto debería ser legal C# o no. Bueno, ¿y si trato de hacerlo de otra manera?

if (typeof(T) == typeof(Hashtable)) { 
    var h = x as Hashtable; // works (and no, h isn't null) 
} 

Eso es un poco raro. De acuerdo con MSDN, expression as Type es (excepto para evaluar la expresión dos veces) lo mismo que expression is type ? (type)expression : (type)null.

¿Qué ocurre si trato de usar la expresión equivalente de los documentos?

if (typeof(T) == typeof(Hashtable)) { 
    var h = (x is Hashtable ? (Hashtable)x : (Hashtable)null); // CS0030: Cannot convert type 'T' to 'System.Collections.Hashtable' 
} 

La única diferencia entre la fundición y documentado as que veo es "el operador as sólo realiza las conversiones de referencia y las conversiones de boxeo". Tal vez necesito decir que estoy usando un tipo de referencia?

T Foo(T x) where T : class { 
    var h = ((Hashtable)x); // CS0030: Cannot convert type 'T' to 'System.Collections.Hashtable' 
    return x; 
} 

¿Qué está pasando? ¿Por qué as funciona bien, mientras que el lanzamiento ni siquiera se compila? ¿Debería funcionar el elenco, o el as no funciona, o hay alguna otra diferencia de idioma entre la conversión y as que no se encuentra en estos documentos de MSDN que encontré?

Answer 1

El operador de conversión en C# puede:

• caja/unbox
• upcast/abatido
• llamada un operador de conversión definida por el usuario

as Hashtable siempre significa que el segundo.

Al eliminar los tipos de valor con la restricción, ha anulado la opción 1, pero sigue siendo ambigua.

---

Éstos son los dos "mejores" se aproxima a que tanto el trabajo:

Hashtable h = x as Hashtable; 
if (h != null) { 
    ... 
} 

o

if (x is Hashtable) { 
    Hashtable h = (Hashtable)(object)x; 
    ... 
} 

Las primeras necesidades sólo un ensayo de tipo, por lo que es muy eficiente. Y el optimizador JIT reconoce el segundo y lo trata como el primero (al menos cuando se trata de tipos no genéricos, no estoy seguro sobre este caso en particular).

Answer 2

"El compilador de C# solo permite el molde implícito los parámetros de tipo genérico a Object, o a los tipos especificados por restricción, como se muestra en el bloque de código 5. Tal conversión implícita es segura de tipo porque cualquier incompatibilidad se descubre en tiempo de compilación."

véase la sección sobre los genéricos y Fundición: http://msdn.microsoft.com/en-us/library/ms379564(v=vs.80).aspx#csharp_generics_topic5

Answer 3

respuesta de Ben básicamente golpea el clavo en la cabeza, pero se expanda en que un poco:

El problema aquí es que la gente tiene un natural la expectativa de que un método genérico hará lo mismo que haría el método no genérico equivalente si se proporcionan los tipos en tiempo de compilación. En su caso particular, la gente esperaría que si T es corto, entonces (int)t debería hacer lo correcto: convierte el corto en un int. Y (double)t debe convertir el corto en un doble. Y si T es byte, entonces (int)t debe convertir el byte en un int, y (double)t debe convertir el byte en un doble ... y ahora quizás empiece a ver el problema. El código genérico que tendríamos que generar tendría básicamente que iniciar el compilador de nuevo en tiempo de ejecución y hacer un análisis de tipo completo, y luego generar dinámicamente el código para hacer la conversión como se esperaba.

Eso es potencialmente costoso; añadimos esa característica en C# 4 y si eso es lo que realmente quiere, puede marcar los objetos como de tipo "dinámico" y una versión reducida del compilador se iniciará nuevamente en el tiempo de ejecución y hará la lógica de conversión para usted .

Pero esa cosa cara normalmente no es lo que la gente quiere.

La lógica "as" es ahora menos complicada que la lógica de conversión, ya que no tiene que ocuparse de otras conversiones que no sean boxeo, unboxing y conversiones de referencia. No tiene que ocuparse de conversiones definidas por el usuario, no tiene que ocuparse de representaciones sofisticadas, como conversiones como "byte a double" que transforman las estructuras de datos de un byte en estructuras de datos de ocho bytes, y así sucesivamente.

Es por eso que "as" está permitido en el código genérico pero los moldes no lo son.

Todo lo dicho: es casi seguro que lo estás haciendo mal. Si tiene que hacer una prueba de tipo en el código genérico , su código no es genérico. Este es un olor de código realmente malo.