Por que o C # falha ao comparar dois tipos de objetos, mas o VB não?

Eu tenho dois objetos em c # e não sei se é booleano ou qualquer outro tipo. No entanto, quando eu tento comparar esses c # falha em dar a resposta certa. Eu tentei o mesmo código com o VB.NET e foi isso!

Alguém pode me dizer como corrigir isso, se houver uma solução?

C #:

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

Em C #, o ==operador (quando aplicado a expressões de tipo de referência) executa uma verificação de igualdade de referência, a menos que esteja sobrecarregada . Você está comparando duas referências que resultam de conversões de boxe, portanto, essas são referências distintas.

EDIT: Com tipos que sobrecarregam ==, você pode obter um comportamento diferente - mas isso é baseado no tipo de expressões em tempo de compilação . Por exemplo, stringfornece ==(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

Aqui, a primeira comparação está usando o operador sobrecarregado, mas a segunda está usando a comparação de referência "padrão".

No VB, o =operador faz muito mais trabalho - nem sequer é equivalente ao uso object.Equals(x, y), pois coisas como isso Option Comparepodem afetar a comparação do texto.

Fundamentalmente, os operadores não funcionam da mesma maneira e não pretendem funcionar da mesma maneira.

Além da resposta de Jon, que explica o lado C #, aqui está o que o VB faz:

No VB com Option Strict On, uma comparação via = sempre testa a igualdade de valor e nunca a igualdade de referência. De fato, seu código nem compila uma vez que você alterna Option Strict Onporque System.Objectnão define um Operator=. Você deve sempre ter essa opção ativada, pois captura bugs com mais eficiência do que uma armadilha de venus (embora no seu caso particular esse comportamento negligente realmente faça a coisa certa). ¹

Na verdade, com Option Strict On, VB comporta-se ainda mais rigoroso do que o C #: Em C #, a == b quer gatilhos uma chamada para SomeType.operator==(a, b)ou, se este não existir, comparação de igualdade de referência invoca (que é equivalente a chamar object.ReferenceEquals(a, b)).

No VB, por outro lado, a comparação a = b sempre chama o operador de igualdade. ² Se você quiser usar a comparação de igualdade de referência, precisará usar a Is b(que é, mais uma vez, o mesmo que Object.ReferenceEquals(a, b)).

¹⁾ Aqui está uma boa indicação do porquê usar Option Strict Offuma péssima idéia: usei o VB.NET por quase uma década, desde o lançamento oficial do .NET até alguns anos atrás, e não faço ideia do que a = bfaz Option Strict Off. Faz algum tipo de comparação de igualdade, mas o que exatamente acontece e por que, não faz ideia. dynamicPorém, é mais complexo que o recurso do C # (porque isso depende de uma API bem documentada). Aqui está o que o MSDN diz:

Como Option Strict Onfornece digitação forte , evita conversões de tipo não intencionais com perda de dados, desabilita a ligação tardia e melhora o desempenho, seu uso é altamente recomendado.

²⁾ Jon mencionou uma exceção, strings, em que a comparação de igualdade faz mais algumas coisas por razões de compatibilidade com versões anteriores.

Instâncias de objeto não são comparadas com o operador "==". Você deve usar o método "igual". Com o operador "==" estão comparando referências, não objetos.

Tente o seguinte:

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

Resultados:

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

Agora, tente o seguinte:

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

Resultados:

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

O problema é que o operador == em C # é uma chamada para um método estático (bem, talvez não tecnicamente, mas pode ser como tal) com base no tipo de tempo de compilação dos dois parâmetros. Quais são os tipos reais de tempo de execução desses objetos não importa.

Com base nesse tipo de tempo de compilação, o compilador determinará qual implementação operator ==usar. Pode usar o padrãoobject implementação , pode usar uma das sobrecargas numéricas fornecidas pelo idioma ou pode ser uma implementação definida pelo usuário.

Isso é diferente do VB, pois o VB não determina a implementação no momento da compilação. Ele espera até o tempo de execução e inspeciona os dois parâmetros que são dados para determinar qual implementação do ==operador ele deve usar.

Seu código contém valores booleanos, mas eles estão em variáveis ​​que são do tipo object. Como a variável é do tipo object, o compilador C # usa a objectimplementação de ==, que compara as referências , não as instâncias do objeto. Como os valores booleanos são caixas, eles não têm a mesma referência, mesmo que seus valores sejam os mesmos.

O código VB não se importa com o tipo da variável. Ele espera até o tempo de execução e, em seguida, verifica as duas variáveis, vê que elas são realmente do tipo booleano e, portanto, usa a ==implementação do operador booleano . Essa implementação compara os valores dos booleanos, não suas referências (e os booleanos serão unboxed antes de chamar a chamada desse operador, portanto, uma comparação de referência nem faz mais sentido). Como os valores dos booleanos são os mesmos, ele retorna true.