Różnica w C # między == a Equals ()

Mam warunek w aplikacji silverlight, która porównuje 2 łańcuchy, z jakiegoś powodu, gdy ==go używam , zwraca false, a .Equals()zwraca true .

Oto kod:

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

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

Masz powód, dlaczego tak się dzieje?

Kiedy ==zostanie użyty do wyrażenia typu object, rozpozna System.Object.ReferenceEquals.

Equalsjest tylko virtualmetodą i zachowuje się jako taka, więc zostanie użyta przesłonięta wersja (która dla stringtypu porównuje zawartość).

Podczas porównywania odwołania do obiektu do łańcucha (nawet jeśli odwołanie do obiektu odnosi się do łańcucha), specjalne zachowanie ==operatora specyficzne dla klasy łańcucha jest ignorowane.

Zwykle (gdy nie ma do czynienia z łańcuchami), Equalsporównuje wartości , a ==porównuje odwołania do obiektów . Jeśli dwa porównywane obiekty odnoszą się do tej samej dokładnej instancji obiektu, wówczas oba zwrócą wartość true, ale jeśli jeden ma tę samą treść i pochodzi z innego źródła (jest osobną instancją z tymi samymi danymi), tylko równa się zwróć prawdę. Jednak, jak zauważono w komentarzach, ciąg znaków jest szczególnym przypadkiem, ponieważ przesłania ==operator, tak więc w przypadku czysto odwołań do ciągów (a nie odwołań do obiektów) porównywane są tylko wartości, nawet jeśli są to osobne wystąpienia. Poniższy kod ilustruje subtelne różnice w zachowaniach:

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));

Dane wyjściowe to:

True True True
False True True
False False True

==i .Equalsoba są zależne od zachowania określonego w rzeczywistym typie i rzeczywistym typie w miejscu połączenia. Obie są tylko metodami / operatorami, które można zastąpić dowolnym rodzajem i biorąc pod uwagę dowolne zachowanie, które autor sobie zażyczy. Z mojego doświadczenia wynika, że ​​ludzie często implementują .Equalsna obiekcie, ale zaniedbują implementację operatora ==. Oznacza to, że .Equalsfaktycznie będzie mierzyć równość wartości podczas== sprawdzi, czy są one tym samym odniesieniem.

Kiedy pracuję z nowym typem, którego definicja jest zmienna lub piszę ogólne algorytmy, uważam, że najlepsza praktyka jest następująca

• Jeśli chcę porównać odniesienia w języku C #, używam Object.ReferenceEquals bezpośrednio (nie jest to konieczne w przypadku ogólnym)
• Jeśli chcę porównać wartości, których używam EqualityComparer<T>.Default

W niektórych przypadkach, gdy uważam, że użycie ==jest niejednoznaczne, jawnie Object.Referenceużyję znaku równości w kodzie, aby usunąć niejednoznaczność.

Eric Lippert niedawno napisał post na blogu na temat tego, dlaczego istnieją 2 metody równości w CLR. Warto przeczytać

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

== Operator

1. Jeśli operandy są typami wartości, a ich wartości są równe, zwraca true, w przeciwnym razie false.
2. Jeśli operandy są typami referencyjnymi z wyjątkiem łańcucha i oba odnoszą się do tej samej instancji (tego samego obiektu), wówczas zwraca true lub false.
3. Jeśli operandy mają ciąg znaków, a ich wartości są równe, to zwraca true, w przeciwnym razie false.

.Równa się

1. Jeśli operandy są typami referencyjnymi , wykonuje równość referencyjną, tzn. Jeśli oba odnoszą się do tej samej instancji (tego samego obiektu), zwraca true, w przeciwnym razie false.
2. Jeśli argumenty są typami wartości, to w przeciwieństwie do operatora ==, najpierw sprawdza ich typ, a jeśli ich typy są takie same, operator ==, w przeciwnym razie zwraca false.

Po pierwsze, jest różnica. Dla liczb

> 2 == 2.0
True

> 2.Equals(2.0)
False

I na smyczki

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

> x.Equals(null)
NullReferenceException

W obu przypadkach ==zachowuje się bardziej użytecznie niż.Equals

O ile rozumiem odpowiedź jest prosta:

1. == porównuje odwołania do obiektów.
2. .Equals porównuje zawartość obiektu.
3. String typy danych zawsze działają jak porównanie zawartości.

Mam nadzieję, że mam rację i że odpowiedział na twoje pytanie.

Dodałbym, że jeśli rzutujesz swój obiekt na ciąg, to zadziała on poprawnie. Dlatego kompilator wyświetli ostrzeżenie:

Możliwe niezamierzone porównanie odniesienia; aby uzyskać porównanie wartości, po lewej stronie wpisz „ciąg”

Ponieważ do .Equaltej pory nie wspomniano o statycznej wersji metody, chciałbym dodać ją tutaj, aby podsumować i porównać 3 warianty.

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

gdzie MyStringjest zmienną pochodzącą z innego miejsca w kodzie.

Informacje w tle i na lato:

W Javie ==do porównywania łańcuchów nie należy używać. Wspominam o tym na wypadek, gdybyś musiał używać obu języków, a także poinformować, że używanie ==można również zastąpić czymś lepszym w języku C #.

W języku C # nie ma praktycznej różnicy w porównywaniu ciągów przy użyciu metody 1 lub metody 2, o ile oba są ciągami typu. Jednakże, jeśli jeden jest pusty, jeden jest innego typu (np. Liczba całkowita) lub jeden reprezentuje obiekt, który ma inne odwołanie, wówczas, jak pokazuje początkowe pytanie, możesz doświadczyć, że porównanie zawartości dla równości może nie zwrócić tego, co oczekujesz.

Sugerowane rozwiązanie:

Ponieważ używanie ==nie jest dokładnie tym samym, co używanie .Equalspodczas porównywania rzeczy, można zamiast tego użyć statycznej metody String.Equals . W ten sposób, jeśli dwie strony nie są tego samego typu, nadal będziesz porównywać zawartość, a jeśli jedna będzie pusta, unikniesz wyjątku.

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

Jest trochę więcej do napisania, ale moim zdaniem bezpieczniejszy w użyciu.

Oto niektóre informacje skopiowane z Microsoft:

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

Parametry

a Strunowy

Pierwszy ciąg do porównania lub null.

b Strunowy

Drugi ciąg do porównania, lub null.

Zwroty Boolean

truejeśli wartość ajest taka sama jak wartość b; w przeciwnym razie false. Jeśli oba są ai , metoda zwraca .bnulltrue

Tylko jako uzupełnienie już dobrych odpowiedzi: To zachowanie NIE jest ograniczone do ciągów znaków lub porównywania różnych typów liczb. Nawet jeśli oba elementy są typu obiektu tego samego typu bazowego. „==” nie będzie działać.

Poniższy zrzut ekranu pokazuje wyniki porównania dwóch wartości obiektu {int}

Jestem tu trochę zdezorientowany. Jeśli typ środowiska wykonawczego Content ma ciąg znaków, zarówno ==, jak i Equals powinny zwracać wartość true. Ponieważ jednak nie wydaje się, że tak się dzieje, typ zawartości w środowisku wykonawczym nie jest ciągiem, a wywołanie na nim równości powoduje równość referencyjną, co wyjaśnia, dlaczego zawodzi równość („atak energii”). Jednak w drugim przypadku decyzja, który przeciążony operator == statyczny powinien zostać wywołany, jest podejmowana w czasie kompilacji i wydaje się, że ta decyzja to == (ciąg, ciąg). sugeruje mi to, że Treść zapewnia niejawną konwersję na ciąg znaków.

Istnieje inny wymiar wcześniejszej odpowiedzi @BlueMonkMN. Dodatkowym wymiarem jest to, że odpowiedź na pytanie tytułowe @ Drahcir, jak zostało powiedziane, zależy również od tego , jak doszliśmy do tej stringwartości. Ilustrować:

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));

Dane wyjściowe to:

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

Dodanie jeszcze jednego punktu do odpowiedzi.

.EqualsTo() ta metoda zapewnia porównanie z kulturą i rozróżnianiem wielkości liter.

==Żeton w C # jest używany dla dwóch różnych operatorów równości sprawdzić. Gdy kompilator napotka ten token, sprawdzi, czy którykolwiek z porównywanych typów zaimplementował przeciążenie operatora równości albo dla konkretnych typów kombinacji, które są porównywane (*), czy dla kombinacji typów, na które oba typy mogą być przekształcone. Jeśli kompilator znajdzie takie przeciążenie, użyje go. W przeciwnym razie, jeśli oba typy są typami referencyjnymi i nie są klasami niepowiązanymi (może to być interfejs lub mogą to być klasy pokrewne), kompilator uwzględni== jako operator porównania referencji. Jeśli żaden warunek nie zostanie spełniony, kompilacja się nie powiedzie.

Zauważ, że niektóre inne języki używają osobnych tokenów dla dwóch operatorów kontroli równości. Na przykład w VB.NET =token jest używany w wyrażeniach wyłącznie dla przeciążalnego operatora sprawdzania równości i Isjest używany jako test odniesienia lub operator testu zerowego. Zastosowanie =typu, który nie zastępuje operatora sprawdzania równości, zakończy się niepowodzeniem, podobnie jak próba użyciaIs w celu innym niż testowanie równości lub nieważności odniesienia.

(*) Typy zazwyczaj przeciążają równość tylko w celu porównania ze sobą, ale może być przydatne dla typów w celu przeciążenia operatora równości w celu porównania z innymi konkretnymi typami; na przykład intmógł (i IMHO powinien, ale nie zdefiniował) zdefiniować operatory równości do porównania float, tak aby 16777217 nie zgłosiłby się jako równy 16777216f. Ponieważ tak się nie dzieje, ponieważ żaden taki operator nie jest zdefiniowany, C # będzie promować intto float, zaokrąglając go do 16777216f, zanim operator kontroli równości zobaczy go; operator ten widzi następnie dwie równe liczby zmiennoprzecinkowe i zgłasza je jako równe, nieświadomy zaokrąglenia, które miało miejsce.

Naprawdę świetne odpowiedzi i przykłady!

Chciałbym tylko dodać podstawową różnicę między nimi,

Operatory takie jak ==nie są polimorficzne, podczas gdy Equalsjest

Mając na uwadze tę koncepcję, jeśli opracujesz dowolny przykład (patrząc na typ odniesienia lewej i prawej ręki oraz sprawdzając / wiedząc, czy typ rzeczywiście ma przeciążony operator == i jest zastępowany równy), na pewno otrzymasz właściwą odpowiedź .

Kiedy tworzymy dowolny obiekt, mamy do czynienia z dwiema częściami, z których jedna stanowi treść, a druga jest odniesieniem do tej treści. ==porównuje zarówno treść, jak i referencje; equals()porównuje tylko treść

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

==

Operator == może być użyty do porównania dwóch zmiennych dowolnego rodzaju i po prostu porównuje bity .

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

Uwaga: po lewej stronie int jest więcej zer, ale tutaj nas to nie obchodzi.

int a (00000011) == bajt b (00000011)

Pamiętaj = = operator dba tylko o wzór bitów w zmiennej.

Użyj == Jeśli dwa odwołania (prymitywy) odnoszą się do tego samego obiektu na stercie.

Reguły są takie same, niezależnie od tego, czy zmienna jest odwołaniem, czy prymitywem.

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 jest prawdą a == b jest fałszem

wzór bitowy jest taki sam dla a i c, więc są one równe przy użyciu ==.

Równy():

Użyj metody equals (), aby sprawdzić, czy dwa różne obiekty są równe .

Takich jak dwa różne obiekty String, które reprezentują znaki w „Jane”

Jedyna różnica między Equal i == polega na porównaniu typów obiektów. w innych przypadkach, takich jak typy referencyjne i typy wartości, są one prawie takie same (oba są równe bitowo lub oba są równe referencyjne).

obiekt: Równa się: równość bitowa ==: równość odniesienia

string: (równe i == są takie same dla ciągu, ale jeśli jeden z ciągów zostanie zmieniony na obiekt, wynik porównania będzie inny) Równa się: równość bitowa ==: równość bitowa

Zobacz tutaj , aby uzyskać więcej wyjaśnień.