Dlaczego C # nie może porównać ze sobą dwóch typów obiektów, ale VB nie?

Mam dwa obiekty w C # i nie wiem, czy jest to typ Boolean, czy inny. Jednak gdy próbuję porównać te C # nie daje poprawnej odpowiedzi. Wypróbowałem ten sam kod z VB.NET i to się udało!

Czy ktoś może mi powiedzieć, jak to naprawić, jeśli istnieje rozwiązanie?

DO#:

object a = true;
object b = true;
object c = false;
if (a == b) c = true;
MessageBox.Show(c.ToString()); //Outputs False !!

VB.NET:

Dim a As Object = True
Dim b As Object = True
Dim c As Object = False
If (a = b) Then c = True
MessageBox.Show(c.ToString()) '// Outputs True

W języku C # ==operator (w przypadku zastosowania do wyrażeń typu referencyjnego) wykonuje sprawdzenie równości odwołań, chyba że jest przeciążony . Porównujesz dwa odniesienia, które są wynikiem konwersji bokserskich, więc są to różne odniesienia.

EDYCJA: W przypadku typów, które przeciążają ==, możesz uzyskać inne zachowanie - ale jest to oparte na typie wyrażeń w czasie kompilacji . Na przykład stringzapewnia ==(string, string):

string x = new string("foo".ToCharArray());
string y = new string("foo".ToCharArray());
Console.WriteLine(x == y); // True
Console.WriteLine((object) x == (object) y); // False

Tutaj pierwsze porównanie używa przeciążonego operatora, ale drugie używa „domyślnego” porównania referencji.

W VB =operator wykonuje o wiele więcej pracy - nie jest to nawet równoważne użyciu object.Equals(x, y), ponieważ takie rzeczy Option Comparemogą wpływać na sposób porównywania tekstu.

Zasadniczo operatory nie działają w ten sam sposób i nie mają działać w ten sam sposób.

Oprócz odpowiedzi Jona, która wyjaśnia stronę C #, oto co robi VB:

W VB z Option Strict On, porównanie poprzez = zawsze sprawdza równość wartości, a nigdy równość odniesienia. W rzeczywistości Twój kod nawet się nie kompiluje po przełączeniu, Option Strict Onponieważ System.Objectnie definiuje pliku Operator=. Powinieneś zawsze mieć tę opcję włączoną, łapie ona owady skuteczniej niż muchołówka (chociaż w twoim konkretnym przypadku to luźne zachowanie działa właściwie). ¹

W rzeczywistości, z Option Strict OnVB zachowuje się jeszcze bardziej rygorystyczne niż C # w C #, a == b albo wyzwala wywołanie SomeType.operator==(a, b)lub, jeśli nie istnieje, powołuje porównania równości odniesienia (co jest równoznaczne z wywołaniem object.ReferenceEquals(a, b)).

Z drugiej strony w języku VB porównanie a = b zawsze wywołuje operator równości. ² Jeśli chcesz użyć porównania równości odniesień, musisz użyć a Is b(co znowu jest tym samym co Object.ReferenceEquals(a, b)).

¹⁾ Oto dobra wskazówka, dlaczego używanie Option Strict Offjest złym pomysłem: korzystałem z VB.NET przez prawie dekadę, od oficjalnego wydania .NET aż do kilku lat temu i nie mam pojęcia, co a = bsię z nim dzieje Option Strict Off. Robi jakieś porównanie równości, ale co dokładnie się dzieje i dlaczego, nie mam pojęcia. Jest to jednak bardziej złożone niż dynamicfunkcja C # (ponieważ opiera się na dobrze udokumentowanym interfejsie API). Oto, co mówi MSDN:

Ponieważ Option Strict Onzapewnia silne pisanie , zapobiega niezamierzonym konwersjom typów z utratą danych, uniemożliwia późne wiązanie i poprawia wydajność, zdecydowanie zaleca się jego użycie.

²⁾ Jon wspomniał o jednym wyjątku, łańcuchach, gdzie porównanie równości robi więcej rzeczy ze względu na kompatybilność wsteczną.

Instancje obiektów nie są porównywane z operatorem „==”. Powinieneś użyć metody „równa się”. Za pomocą operatora „==” porównujemy referencje, a nie obiekty.

Spróbuj tego:

public class MyObject
{
    public MyObject(String v)
    {
        Value = v;
    }
    public String Value { get; set; }
}

MyObject a = new MyObject("a");
MyObject b = new MyObject("a");
if(a==b){
    Debug.WriteLine("a reference is equal to b reference");
}else{
    Debug.WriteLine("a reference is not equal to b reference");
}
if (a.Equals(b)) {
    Debug.WriteLine("a object is equal to b object");
} else {
    Debug.WriteLine("a object is not equal to b object");
}

Wyniki:

a reference is not equal to b reference
a object is not equal to b object

Teraz spróbuj tego:

public class MyObject
{
    public MyObject(String v)
    {
        Value = v;
    }
    public String Value { get; set; }

    public bool Equals(MyObject o)
    {
        return (Value.CompareTo(o.Value)==0);
    }
}
MyObject a = new MyObject("a");
MyObject b = new MyObject("a");
if(a==b){
    Debug.WriteLine("a reference is equal to b reference");
}else{
    Debug.WriteLine("a reference is not equal to b reference");
}
if (a.Equals(b)) {
    Debug.WriteLine("a object is equal to b object");
} else {
    Debug.WriteLine("a object is not equal to b object");
}

Wyniki:

a reference is not equal to b reference
a object is equal to b object

Problem polega na tym, że operator == w C # jest wywołaniem metody statycznej (no może nie technicznie, ale może być tak pomyślana) na podstawie typu czasu kompilacji dwóch parametrów. Nie ma znaczenia, jakie są rzeczywiste typy środowiska uruchomieniowego tych obiektów.

Na podstawie tego typu czasu kompilacji kompilator określi, której implementacji operator ==użyć. Może używać domyślnej objectimplementacji, może używać jednego z przeciążeń numerycznych dostarczonych przez język lub może to być implementacja zdefiniowana przez użytkownika.

Różni się to od VB tym, że VB nie określa implementacji w czasie kompilacji. Czeka do czasu wykonania i sprawdza dwa parametry, które otrzymuje, aby określić, której implementacji ==operatora powinien użyć.

Twój kod zawiera wartości logiczne, ale są one w zmiennych typu object. Ponieważ zmienna jest typu object, kompilator C # używa objectimplementacji ==, która porównuje odwołania , a nie wystąpienia obiektów. Ponieważ wartości logiczne to pola, nie mają tego samego odniesienia, mimo że ich wartości są takie same.

Kod VB nie dba o typ zmiennej. Czeka do czasu uruchomienia, a następnie sprawdza dwie zmienne, widzi, że obie są w rzeczywistości typu boolowskiego, więc używa ==implementacji operatora boolowskiego . Ta implementacja porównuje wartości parametrów logicznych, a nie ich referencji (a wartości logiczne zostaną rozpakowane przed wywołaniem tego operatora, więc porównanie referencji nie ma już nawet sensu). Ponieważ wartości logiczne są takie same, zwraca prawdę.