¿Por qué la implementación predeterminada == no llama igual?

Question

Duplicar posible:
Why ReferenceEquals and == operator behave different from Equals

La implementación predeterminada de == operador compara objetos por referencias. Por lo tanto, cuando anula Equals (el comportamiento predeterminado es el mismo), también debe especificar los operadores == y != para que invoquen Equals (y lo hagan en cada clase de jerarquía ya que los operadores == y != no son virtuales).

Mi pregunta es ¿por qué es así? ¿Por qué == y != comparan objetos por referencia en lugar de usar Equals? Supongo que debería haber una razón para algo tan fundamental.

Actualización.

Para comentarios: Me supone == debe depender de Iguales (pero no viceversa) como se puede anular iguales en la clase base y utilizar esta aplicación en las clases derivadas automáticamente. No funcionaría si Equals usó == en su implementación, ya que == no es virtual.

Answer 1

Object.ReferenceEquals es un miembro static que compara referencia igualdad. Incluso los tipos de valores están encuadrados antes de pasarlos a ese método.

¿Qué hay de Equals, es un método virtual, lo que significa que permite a un consumidor a anulación una funcionalidad.

aplicación tanto por defecto de == comportamiento supone la comparación por defecto (referencia) es aceptable para usted, si necesita algo específico, en este caso marco le proporciona un método virtual, que puede ser anulado.

Answer 2

Creo que la razón principal es == es un operador de estática y pueden ser llamados en null objetos mientras Equalsrequiere una instancia.

Por ejemplo:

Foo foo1 = null; 
Foo foo2 = null; 

Console.WriteLine(foo1 == foo2); // cannot use Equals 

Answer 3

El == ha existido y utilizado como referencia ya que C, y está integrado en la sintaxis del lenguaje en lugar de tener que responder en la invocación de métodos (Incluso si los resultados son los mismos para ambos).

Simplemente, debido a que C# no es Objective C :)

Answer 4

La "razón" es porque a veces uno necesita saber si A es la misma instancia como B en lugar de si son o no son más que "igual "el uno al otro.

Por ejemplo, dos objetos son iguales entre sí puede tener sentido para la mayoría de la lógica de negocio, sin embargo, también puede ser necesario utilizar algunos servicios públicos de concurrencia que hacen operaciones atómicas en que los resultados dependen de la identidad del objeto, no la igualdad .

Answer 5

En Java, a veces es bueno determinar rápidamente si dos identificadores son iguales simplemente comparando las referencias. == tiene su lugar. Si nos fijamos en un método IDE generado equals, a menudo encontrará que la primera comparación realizada es la igualdad de referencia, después de todo, ¿por qué verificar los campos si las referencias de objeto son las mismas?

Answer 6

Lo llamaría una característica. Por referencia, dos objetos idénticos son todavía dos objetos separados. Si anula Equals, puede determinar si dos objetos son idénticos. Incluso si dos objetos son idénticos, también podría querer probar si son el mismo objeto. A menudo tengo razones para anular iguales, pero nunca tuve la necesidad de anular ==! = (Pero ese lenguaje proporciona esa opción).

Con cadena, anulan == y no me gusta. Aunque string es un tipo de referencia, los operadores de igualdad (== y! =) Se definen para comparar los valores de los objetos de cadena, no de las referencias (7.9.7 Operadores de igualdad de cadenas). Esto hace que las pruebas de igualdad de cadenas sean más intuitivas. Vea el problema que esto introdujo. WPF ListBox Scroll to the bottom