2012-02-10 9 views
33

ReSharper sugiere que se cambie la siguiente a partir de:C# Tipo Comparación: Type.Equals vs == operador

Type foo = typeof(Foo); 
Type bar = typeof(Bar); 

if(foo.Equals(bar)) { ... } 

Para:

if(foo == bar) { ... } 

== operador

// Summary: 
//  Indicates whether two System.Type objects are equal. 
// 
// Parameters: 
// left: 
//  The first object to compare. 
// 
// right: 
//  The second object to compare. 
// 
// Returns: 
//  true if left is equal to right; otherwise, false. 
public static bool operator ==(Type left, Type right); 

Igual (Tipo o)

// Summary: 
//  Determines if the underlying system type of the current System.Type is the 
//  same as the underlying system type of the specified System.Type. 
// 
// Parameters: 
// o: 
//  The System.Type whose underlying system type is to be compared with the underlying 
//  system type of the current System.Type. 
// 
// Returns: 
//  true if the underlying system type of o is the same as the underlying system 
//  type of the current System.Type; otherwise, false. 
public virtual bool Equals(Type o); 

Pregunta
¿Por qué operator == recomendar más Equals(Type o) al comparar los tipos?

Respuesta

32

Le sugiero que lea la excelente publicación del blog when is a type not a type? de Brad Wilson. Para resumir: un tipo de tiempo de ejecución (representado por el tipo interno RuntimeType), administrado por el CLR no es siempre el mismo que el Type, que se puede extender. Equals comprobará el underlying system type, mientras que == comprobará el tipo en sí.

Un ejemplo sencillo:

Type type = new TypeDelegator(typeof(int)); 
Console.WriteLine(type.Equals(typeof(int))); // Prints True 
Console.WriteLine(type == typeof(int));  // Prints False 
5

La razón es simple: los dos son funcionalmente equivalentes en este caso y el último es más legible.

+0

R # típicamente sugerirá algo y dar una razón válida; en este caso, si son funcionalmente equivalentes, tengo dudas de que la sugerencia sea legibilidad, que es subjetiva. Me pregunto si hay otra razón por la que se sugiera. –

+0

@MetroSmurf - R # a menudo sugiere cosas en aras de la legibilidad (reduciendo la anidación en las declaraciones if, por ejemplo). –

+5

Probablemente esa sea la razón prevista, pero como los dos no son funcionalmente equivalentes en este caso, ¿entonces seguramente esto es un error en Resharper? –

1

De http://blogs.msdn.com/b/csharpfaq/archive/2004/03/29/when-should-i-use-and-when-should-i-use-equals.aspx

El método equals es sólo una virtual se define en System.Object, y anulado por lo que las clases deciden hacerlo. El operador == es un operador que puede estar sobrecargado por clases, pero que generalmente tiene un comportamiento de identidad .

Para los tipos de referencia donde == no se ha sobrecargado, compara si dos referencias se refieren al mismo objeto, que es exactamente lo que hace la implementación de Equals en System.Object.

Los tipos de valor no proporcionan una sobrecarga para == de manera predeterminada. Sin embargo, la mayoría de los tipos de valores proporcionados por el marco proporcionan su propia sobrecarga . La implementación predeterminada de Igual para un tipo de valor es proporcionada por ValueType, y usa la reflexión para hacer la comparación, , lo que la hace significativamente más lenta que una implementación de tipo normalmente. Esta implementación también llama a Igual a los pares de referencias dentro de los dos valores que se comparan.

Sin embargo, la diferencia principal entre los dos tipos de comparación en el uso normal de (donde es poco probable que defina sus propios tipos de valores muy a menudo) es el polimorfismo. Los operadores están sobrecargados, no anulados, lo que significa que a menos que el compilador sepa llamar a la versión más específica , simplemente llamará a la versión de identidad.

Cuestiones relacionadas