C# diferencia entre == y equals()

Question

tengo una condición en una aplicación de Silverlight que compara 2 cadenas, por alguna razón, cuando uso == Devuelve falsa mientras .Equals() vuelve cierto.

Aquí está el código:

if (((ListBoxItem)lstBaseMenu.SelectedItem).Content.Equals("Energy Attack")) 
{ 
    // Execute code 
} 

if (((ListBoxItem)lstBaseMenu.SelectedItem).Content == "Energy Attack") 
{ 
    // Execute code 
} 

Cualquier razón de por qué está sucediendo esto?

Answer 1

Cuando == se usa en una expresión de tipo object, se resolverá en System.Object.ReferenceEquals.

Equals es sólo un método virtual y se comporta como tal, por lo que la versión anulado se utilizará (que, por string tipo compara el contenido).

Answer 2

Al comparar una referencia de objeto a una cadena (incluso si la referencia del objeto hace referencia a una cadena), se ignora el comportamiento especial del operador == específico de la clase de cadena.

Normalmente (cuando no se trata de cadenas, que es), Equals compara valores, mientras == compara referencias a objetos. Si dos objetos que está comparando se refieren a la misma instancia exacta de un objeto, ambos serán verdaderos, pero si uno tiene el mismo contenido y proviene de una fuente diferente (es una instancia separada con los mismos datos), solo equivale volverá verdadero. Sin embargo, como se señala en los comentarios, la cadena es un caso especial porque anula al operador ==, de modo que cuando se trata exclusivamente de referencias de cadenas (y no de referencias a objetos), solo se comparan los valores incluso si son instancias separadas. El código siguiente ilustra las sutiles diferencias en los comportamientos:

string s1 = "test"; 
string s2 = "test"; 
string s3 = "test1".Substring(0, 4); 
object s4 = s3; 
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s2), s1 == s2, s1.Equals(s2)); 
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s3), s1 == s3, s1.Equals(s3)); 
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s4), s1 == s4, s1.Equals(s4)); 

la salida es:

True True True 
False True True 
False False True 

Answer 3

== y .Equals son ambos depende de la conducta se define en el tipo real y el tipo real en el sitio de llamada . Ambos son solo métodos/operadores que pueden ser anulados en cualquier tipo y dado cualquier comportamiento que el autor así lo desee. En mi experiencia, me parece que es común que las personas implementen .Equals en un objeto pero no implementen el operador ==. Esto significa que .Equals realmente medirá la igualdad de los valores, mientras que == medirá si son la misma referencia o no.

Cuando estoy trabajando con un nuevo tipo cuya definición es en flujo o escribir algoritmos genéricos, creo que la mejor práctica es la siguiente

• Si quiero comparar referencias en C#, yo uso Object.ReferenceEquals directamente (no es necesario en el caso genérico)
• Si quiero comparar los valores que utilizo EqualityComparer<T>.Default

en algunos casos, cuando siento el uso de == es ambigua voy a utilizar de forma explícita Object.Reference es igual en el código para eliminar la ambigüedad.

Eric Lippert recientemente hizo una publicación de blog sobre el tema de por qué hay 2 métodos de igualdad en el CLR. Vale la pena leer el

• http://blogs.msdn.com/ericlippert/archive/2009/04/09/double-your-dispatch-double-your-fun.aspx

Answer 4

Estoy un poco confundido aquí. Si el tipo de contenido de tiempo de ejecución es de tipo cadena, ambos == e Igual deben devolver verdadero. Sin embargo, dado que este no parece ser el caso, entonces el tipo de contenido en tiempo de ejecución no es una cadena y llamar a Igual en él está haciendo una igualdad referencial y esto explica por qué Equals ("Energy Attack") falla. Sin embargo, en el segundo caso, la decisión sobre a qué operador sobrecargado == static se debe llamar se realiza en tiempo de compilación y esta decisión parece ser == (string, string). esto me sugiere que el Contenido proporciona una conversión implícita a la cadena.

Answer 5

Yo agregaría que si lanzas tu objeto a una cadena, entonces funcionará correctamente. Esta es la razón por la cual el compilador le dará una advertencia diciendo "Posible comparación de referencia no intencionada; para obtener una comparación de valor, envíe el lado izquierdo para escribir 'cadena'"

Answer 6

Agregando un punto más a la respuesta.

.EqualsTo() método le ofrece la posibilidad de comparar con la cultura y las mayúsculas y minúsculas.

Answer 7

== operador 1. Si los operandos son Value Types y sus valores son iguales, devuelve true y false. 2. Si los operandos son Reference Types con excepción del string y ambos se refieren al mismo objeto, devuelve true else false. 3. Si los operandos son de tipo serie y sus valores son iguales, devuelve true else false.

.equals 1. Si los operandos son los tipos de referencia, se realiza Reference Equality es decir, si ambos se refieren al mismo objeto, devuelve true y false. 2. Si los operandos son tipos de valor, a diferencia del operador ==, primero verifica su tipo y si sus tipos son iguales, realiza == operator else devuelve falso.

Answer 8

En primer lugar, hay es una diferencia. Para los números de

> 2 == 2.0 
True 

> 2.Equals(2.0) 
False 

Y para cuerdas

> string x = null; 
> x == null 
True 

> x.Equals(null) 
NullReferenceException 

En ambos casos, == se comporta más útil que .Equals

Answer 9

El token == en C# se utiliza para dos operadores de igualdad de verificación diferentes. Cuando el compilador encuentra ese token, verificará si alguno de los tipos que se comparan ha implementado una sobrecarga del operador de igualdad para los tipos de combinación específicos que se comparan (*) o para una combinación de tipos a los que se pueden convertir ambos tipos. Si el compilador encuentra tal sobrecarga, la usará. De lo contrario, si los dos tipos son ambos tipos de referencia y no son clases no relacionadas (ya sea una interfaz o pueden ser clases relacionadas), el compilador considerará == como un operador de comparación de referencia. Si no se cumple ninguna condición, la compilación fallará.

Tenga en cuenta que algunos otros idiomas usan tokens separados para los dos operadores de verificación de igualdad. En VB.NET, por ejemplo, el token = se usa dentro de las expresiones exclusivas para el operador de verificación de igualdad descargable, y Is se utiliza como operador de prueba de referencia o prueba nula. An para usar = en un tipo que no anula el operador de comprobación de igualdad fallará, como se intentará utilizar Is para cualquier propósito que no sea la prueba de igualdad o nulidad de referencia.

(*) Los tipos generalmente solo sobrecargan la igualdad para su comparación, pero puede ser útil que los tipos sobrecarguen el operador de igualdad para compararlo con otros tipos particulares; por ejemplo, int podría haber (y en mi humilde opinión debería haberlo hecho) un operador de igualdad para comparar con float, de modo que 16777217 no se reportaría igual a 16777216f. Tal como está, dado que no se define dicho operador, C# promocionará int a float, redondeándolo a 16777216f antes de que el operador de verificación de igualdad lo vea; ese operador luego ve dos números de coma flotante iguales y los reporta como iguales, sin darse cuenta del redondeo que tuvo lugar.

Answer 10

Cuando creamos cualquier objeto, hay dos partes en el objeto, una es el contenido y la otra es referencia a ese contenido. == compara contenido y referencia; equals() compara sólo el contenido

http://www.codeproject.com/Articles/584128/What-is-the-difference-between-equalsequals-and-Eq

Answer 11

==

El operador == se puede utilizar para comparar dos variables de cualquier tipo, y que simplemente compara los bits de.

int a = 3; 
byte b = 3; 
if (a == b) { // true } 

Nota: hay más ceros en el lado izquierdo de la int pero no se preocupan por eso aquí.

int a (00000011) == byte b (00000011)

Recuerde == operador sólo se preocupa por el patrón de los bits en la variable.

Usar == Si dos referencias (primitivas) se refiere al mismo objeto en el montón.

Las reglas son las mismas si la variable es de referencia o primitiva.

Foo a = new Foo(); 
Foo b = new Foo(); 
Foo c = a; 

if (a == b) { // false } 
if (a == c) { // true } 
if (b == c) { // false } 

a == c es cierto a == b es falsa

el patrón de bits son los mismos para a y c, por lo que son iguales usando ==.

Equal():

Utiliza los método equals() para ver Si dos objetos diferentes son iguales.

tal como dos objetos String diferentes que tanto representar los caracteres en "Jane"

Answer 12

La única diferencia entre igual y == es en la comparación tipo de objeto. en otros casos, como los tipos de referencia y los tipos de valores, son casi los mismos (ambos son iguales a los bits o ambos son igualdad de referencia).

objeto: Igual: bit a bit igualdad ==: la igualdad referencia

cadena: (igual == y son los mismos para cuerda, pero si uno de cadena cambió a oponerse, a continuación, resultado de la comparación serán diferente) Igual a: igualdad de bits ==: igualdad de bits

Consulte here para obtener más información.

Answer 13

Hay otra dimensión en una respuesta anterior de @BlueMonkMN. La dimensión adicional es que la respuesta a la pregunta del título @ Drahcir como se indica también depende de cómo llegamos al valor string. Para ilustrar:

string s1 = "test"; 
string s2 = "test"; 
string s3 = "test1".Substring(0, 4); 
object s4 = s3; 
string s5 = "te" + "st"; 
object s6 = s5; 
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s2), s1 == s2, s1.Equals(s2)); 

Console.WriteLine("\n Case1 - A method changes the value:"); 
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s3), s1 == s3, s1.Equals(s3)); 
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s4), s1 == s4, s1.Equals(s4)); 

Console.WriteLine("\n Case2 - Having only literals allows to arrive at a literal:"); 
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s5), s1 == s5, s1.Equals(s5)); 
Console.WriteLine("{0} {1} {2}", object.ReferenceEquals(s1, s6), s1 == s6, s1.Equals(s6)); 

La salida es:

True True True 

    Case1 - A method changes the value: 
False True True 
False False True 

    Case2 - Having only literals allows to arrive at a literal: 
True True True 
True True True 

Answer 14

realmente grandes respuestas y ejemplos!

me gustaría añadir la diferencia fundamental entre los dos,

Los operadores como == no son polimórficos, mientras Equals es

Con este concepto en mente, si usted se resuelve cualquier ejemplo (al mirar el tipo de referencia de la mano derecha y la mano izquierda, y verificar/saber si el tipo tiene realmente sobrecarga = operador e Igual que sobreescribirlo) está seguro de obtener la respuesta correcta.

Answer 15

Por lo que yo entiendo que la respuesta es simple:

1. == compara las referencias a objetos.
2. .Equals compara el contenido del objeto.
3. Los tipos de datos de cadenas siempre actúan como comparación de contenido.

Espero que esté en lo correcto y que haya respondido a su pregunta.

Answer 16

Como la versión estática del método .Equal no se mencionó hasta ahora, me gustaría agregar esto aquí para resumir y comparar las 3 variaciones.

MyString.Equals("Somestring"))   //Method 1 
MyString == "Somestring"    //Method 2 
String.Equals("Somestring", MyString); //Method 3 (static String.Equals method) - better 

donde MyString es una variable que viene de alguna otra parte del código.

información de fondo y para summerize:

En Java utilizando == para comparar cadenas no deben utilizarse. Menciono esto en caso de que necesite usar ambos idiomas y también para hacerle saber que el uso de == también se puede reemplazar con algo mejor en C#.

En C# no hay ninguna diferencia práctica para comparar cadenas utilizando el Método 1 o el Método 2, siempre que ambas sean de tipo cadena.Sin embargo, si uno es nulo, uno es de otro tipo (como un entero), o uno representa un objeto que tiene una referencia diferente, entonces, como muestra la pregunta inicial, puede experimentar que comparar el contenido para la igualdad puede no devolver lo que tu esperas.

solución sugerida:

Dado que el uso == no es exactamente lo mismo que usar .Equals al comparar las cosas, se puede utilizar el String.Equals estáticas método en su lugar. De esta forma, si las dos partes no son del mismo tipo, igual compararás el contenido y si uno es nulo, evitarás la excepción.

bool areEqual = String.Equals("Somestring", MyString); 

Es un poco más para escribir, pero en mi opinión, más seguro de usar.

Aquí hay alguna información copiada de Microsoft:

public static bool Equals (string a, string b); 

Parámetros

a cadena

La primera cadena de comparar, o null.

b cadena

La segunda cadena de comparar, o null.

devoluciones Boolean

true si el valor de a es el mismo que el valor de b; de lo contrario, false. Si ambos a y b son null, el método devuelve true.