Possible Duplicate:
Why ReferenceEquals and == operator behave different from Equals
The default implementation of == operator compares objects by references. So when you override Equals (which default behaviour is the same) you have to also specify == and != operators so that they call Equals (and make it in every class of hierarchy as == and != operators are not virtual).
My question is why it is so? Why does == and != compare objects by reference instead of using Equals? I guess there should be a reason for such a fundamental thing.
Update.
To comments: I assumed == should depend on Equals (but not vice versa) as you can override Equals in base class and use this implementation in derived classes automatically. It wouldn't work if Equals used == in its implementation, as == is not virtual.
Source: Tips4all, CCNA FINAL EXAM
I believe the main reason is == is a static operator and can be called on null objects while Equals requires an instance.
ReplyDeleteFor example:
Foo foo1 = null;
Foo foo2 = null;
Console.WriteLine(foo1 == foo2); // cannot use Equals
Object.ReferenceEquals is a static member that compares reference equality. Even value types are boxed before being passed to that method.
ReplyDeleteWhat about Equals, it's a virtual method, which means it lets to a consumer to override a functionality.
So default implementation of == behavior presumes default comparison(reference) is ok for you, if you need something specific, in this case framework provides you with a virtual method, which can be overriden.
The "reason" is because sometimes one needs to know if A is the same instance as B as opposed to whether or not they are merely "equal" to each other.
ReplyDeleteFor example, two objects being equal to each other may make sense for most of your business logic, however, you may also need to utilize some concurrency utilities which do atomic operations where the results are dependent on object identity, not equality.
The == has been around and used for reference since C, and it's integrated into the language syntax rather than having to reply on method invocation (Even if results are the same for both).
ReplyDeleteSimply, because C# is not Objective C :)
In Java, it is sometimes nice to quickly determine whether or not two identifiers are equal by simply comparing the references. == has it's place. If you look at an IDE generated equals method, you will often find that the first comparison made is reference equality, after all, why check the fields if the object references are the same?
ReplyDeleteI would call it a feature. By reference two identical objects are still two separate objects. If you override Equals then you can determine if two objects are identical. Even if two objects are identical I also might want to test if the are the same object. I often have reason to override equals but never had the need to override == != (but that language provides that option).
ReplyDeleteWith string they override == and I don't like it. Although string is a reference type, the equality operators (== and !=) are defined to compare the values of string objects, not references (7.9.7 String equality operators). This makes testing for string equality more intuitive. See the problem this introduced. WPF ListBox Scroll to the bottom