1

Topic: Explain about redefinition Equals (object)

I dig in another's code I See: class TMy {//.... public override bool Equals (object obj) {if (ReferenceEquals (null, obj)) return false; if (ReferenceEquals (this, obj)) return true; return obj. GetType () == GetType () && Equals ((TMy) obj);} public override int GetHashCode () {unchecked {//BLA-BLA-BLA return hashCode;}};//class TMy Explain,  - what for here put Equals (object)? In my opinion by default it does exactly too most. Not? At me all these nuances already disappeared from a head. Like was that if you redefine GetHashCode it is necessary to redefine Equals. I tried  this Equals - all gathered (VS2017.FW4.6.2)

2

Re: Explain about redefinition Equals (object)

Hello, Kovalenko Dmitry, you wrote: > In my opinion by default it does exactly too most. Not? . https://msdn.microsoft.com/en-us/library/bsc2ak47.aspx If the current instance is a reference type, the Equals (Object) method tests for reference equality, and a call to the Equals (Object) method is equivalent to a call to the ReferenceEquals method. Reference equality means that the object variables that are compared refer to the same object. Try to launch here this of the code. class MyClass: IEquatable <MyClass> {public int a = 1; public bool Equals (MyClass other) {Console. WriteLine ("Typed Equals is called"); return this.a. Equals (other.a);}} public partial class Program {public static void Main (string [] args) {object a = new MyClass (); object b = new MyClass (); Console. WriteLine (a. Equals (b));//Typified Equals it will not be caused. Console. WriteLine (((MyClass) a).Equals ((MyClass) b));}} an output: False Typed Equals is called True

3

Re: Explain about redefinition Equals (object)

Hello, Kovalenko Dmitry, you wrote: > > class TMy > {>//.... > public override bool Equals (object obj) > {> if (ReferenceEquals (null, obj)) > return false; > if (ReferenceEquals (this, obj)) > return true; > return obj. GetType () == GetType () && Equals ((TMy) obj); >} > public override int GetHashCode () > {> unchecked > {>//BLA-BLA-BLA > return hashCode; >} >};//class TMy > > Explain,  - what for here put Equals (object)? > In my opinion by default it does exactly too most. Not? No. By default, basic Equals does not cause typified Equals (see the selected part). On the idea, all salt should be in it - if nearby is not present public bool Equals (TMy other) this code is simply incorrect (falls down in the infinite recursion by a call on two incoincident links on TMy). And if is, in it structural equivalence (like this.x == other.x) which by default for reference-types does not work, most likely, is described. > Like was that if you redefine GetHashCode it is necessary to redefine Equals. Generally - on the contrary. Hash codes should coincide with equivalence classes, that is at two objects for which different hash codes are returned, Equals is obliged to return false. Otherwise the accelerated comparing will say lies. By default for objects of referens-types their equivalence class includes only this object. When we overload Equals, as a rule, we expand equivalence class;  the hash code at such Equals becomes incorrect, since identical with .. Equals objects return different hash codes. Here also it is necessary to repair GetHashCode for classes with overloaded Equals. In the opposite direction this restriction (almost) is not present: I can overload GetHashCode my class in return 0; And no functionality suffers (only productivity).