Answer Posted / bhagyesh

The Equals method is just a virtual one defined in
System.Object, and overridden by whichever classes choose
to do so. The == operator is an operator which can be
overloaded by classes, but which usually has identity
behaviour.

For reference types where == has not been overloaded, it
compares whether two references refer to the same object -
which is exactly what the implementation of Equals does in
System.Object.

Value types do not provide an overload for == by default.
However, most of the value types provided by the framework
provide their own overload. The default implementation of
Equals for a value type is provided by ValueType, and uses
reflection to make the comparison, which makes it
significantly slower than a type-specific implementation
normally would be. This implementation also calls Equals on
pairs of references within the two values being compared.

However, the main difference between the two types of
comparison in normal use (where you're unlikely to be
defining your own value types very often) is polymorphism.
Operators are overloaded, not overridden, which means that
unless the compiler knows to call the more specific
version, it'll just call the identity version. To
illustrate that, here's an example:

using System;

public class Test
{
static void Main()
{
// Create two equal but distinct strings
string a = new string(new char[]
{'h', 'e', 'l', 'l', 'o'});
string b = new string(new char[]
{'h', 'e', 'l', 'l', 'o'});

Console.WriteLine (a==b);
Console.WriteLine (a.Equals(b));

// Now let's see what happens with the same tests
but
// with variables of type object
object c = a;
object d = b;

Console.WriteLine (c==d);
Console.WriteLine (c.Equals(d));
}
}

The results are:

True
True
False
True

The third line is False because the compiler can only call
the non-overloaded version of == as it doesn't know that
the contents of c and d are both string references. As they
are references to different strings, the identity operator
returns false.

So, when should you use which operator? My rule of thumb is
that for almost all reference types, use Equals when you
want to test equality rather than reference identity. The
exception is for strings - comparing strings with == does
make things an awful lot simpler and more readable but you
need to remember that both sides of the operator must be
expressions of type string in order to get the comparison
to work properly.

For value types, I'd normally use == for easier-to-read
code. Things would get tricky if a value type provided an
overload for == which acted differently to Equals, but I'd
consider such a type very badly designed to start with.

What is server redirect?

1026

---

Which of the following .NET framework supports Web API?

1145

---

What is intrinsic objects in asp.net?

1290

---

What are the advantages of using sql stored procedures instead of adhoc sql queries in an asp.net web application?

1175

---

What are the different kinds of assemblies?

994

---

What does the .webpart file do?

1076

---

What are the different types of validation controls in asp.net?

1108

---

Which browsers support the xmlhttprequest object?

1077

---

What are session state modes in asp.net?

1089

---

How do you open a page in a new window?

1020

---

How you can return View from ASP.NET Web API method?

1055

---

Explain the namespace classes used in asp.net mvc? : asp.net mvc

1043

---

What is http protocol and how it works?

1100

---

What is postback and autopostback in asp.net?

1058

---

What is the difference between session.abandon() vs clear()?

1021

---