Object.Equals causes lots of mistakes.

Object.Equals causes lots of mistakes.

• Ricardo Pinto

  Yes, the relationship between the equals method and the getHashCode method make it a huge work to implement Equals.

  However,if the class BitArray has a system equal method, It can be much more efficient, because it can use int to companion. If we implement equal(BitArray,BitArray),we had to compare each bit. But as it doesn't improve the time complexity. We can admit it.

  Ok, it's just my hoping. I've really haven't seen a IDE like visual c#. I just think the c# language should be as good as the IDE :)

  Thank you.

  
  

• Dee_dotnet_79

  You could write your own methods for comparing the contents of IEnumerable collections of IComparable items.
  
  For example, here are a couple of methods. The first compares typesafe generic collections, the other compares object based collections:
  
  

  private bool Compare<T>(IEnumerable<T> lhs, IEnumerable<T> rhs) where T: IComparable {     if (lhs == rhs)         return true;     if ((lhs == null) || (rhs == null))  // One is null, the other isn't.         return false;                    // Therefore, must be different.     IEnumerator<T> enumLhs = lhs.GetEnumerator();     IEnumerator<T> enumRhs = rhs.GetEnumerator();     for (;;)     {         bool moreLhs = enumLhs.MoveNext();         bool moreRhs = enumRhs.MoveNext();         if (!moreLhs && !moreRhs)   // Both reached end at same time.             return true;         if (moreLhs != moreRhs)     // Unequal lengths.             return false;         if (enumLhs.Current.CompareTo(enumRhs.Current) != 0)             return false;     } } private bool Compare<T>(IEnumerable lhs, IEnumerable rhs) where T: IComparable {     if (lhs == rhs)         return true;     if ((lhs == null) || (rhs == null))  // One is null, the other isn't.         return false;                    // Therefore, must be different.     IEnumerator enumLhs = lhs.GetEnumerator();     IEnumerator enumRhs = rhs.GetEnumerator();     for (;;)     {         bool moreLhs = enumLhs.MoveNext();         bool moreRhs = enumRhs.MoveNext();         if (!moreLhs && !moreRhs)   // Both reached end at same time.             return true;         if (moreLhs != moreRhs)     // Unequal lengths.             return false;         if (((T)enumLhs.Current).CompareTo((T)enumRhs.Current) != 0)             return false;     } } private void button1_Click(object sender, EventArgs e) {     BitArray a1 = new BitArray(3);     BitArray a2 = new BitArray(5);     bool same = Compare<bool>(a1, a2);     MessageBox.Show(same "Same" : "Different");     int[] ia1 = { 1, 2, 3, 4, 5 };     int[] ia2 = { 1, 2, 3, 4, 6 };     same = Compare(ia1, ia2);     MessageBox.Show(same "Same" : "Different"); }

  
  
  
  

• Shippa

  Liu Wei wrote:

  I think object.Equals in .net framework is a really bad method: it's implemented somewhere,but in many other place,it's just a wraper of ReferenceEqual. In a recent project, i use BitArray's Equals to compare two BitArray and of necessity, it's not overloaded and is still object's Equals.So two BitArray like "010010" and "010010" are "not equal". It cost me much time to find where the problem is. So,I think the better implementation of object's Equal should throw NotImplementedException. In such a case,at least we can find what has caused the problem. To be frankly, I would say dotNet's class library has lots of bugs,many helpful but simple method is not implemented correctly. Many object oriented method is used in bad way,and make it hard to write good codes.In the mass, the system.collections namespace need really many work to fix the bugs. There's some other bugs in dotNet framework. // bug1. Array a1=new int[]{1,2,3}; Array a2=new int[]{1,2,3}; // a1.Equals(a2)==false; // bug2. ArrayList a1=new ArrayList(); ArrayList a2=new ArrayList(); // a1.Equals(a2)==false; All these bugs doesnt exist in java. So I think Microsoft should do some work to fix them.

  Relaxed Dear ,

  Before Blaming anyone and thinking that some Design Consideration is a bug, See MSDN to know what object.Equals() Method means:

  "The default implementation of Equals supports reference equality only, but derived classes can override this method to support value equality.

  For reference types, equality is defined as object equality; that is, whether the references refer to the same object. For value types, equality is defined as bitwise equality. The ValueType class supports value types.

  Notes to Implementers This method can be overridden by a derived class. For example, many of the base data types return true if both objects represent the same value; otherwise, false. This method only compares primitives and objects. It must be overridden to compare more complex structures, such as arrays of objects. The following statements must be true for all implementations of the Equals method. In the list, x, y, and z represent object references that are not a null reference (Nothing in Visual Basic).

  • x.Equals(x) returns true, except in cases that involve floating-point types. See IEC 60559:1989, Binary Floating-point Arithmetic for Microprocessor Systems.

  • x.Equals(y) returns the same value as y.Equals(x).

  • x.Equals(y) returns true if both x and y are NaN.

  • (x.Equals(y) && y.Equals(z)) returns true if and only if x.Equals(z) returns true.

  • Successive calls to x.Equals(y) return the same value as long as the objects referenced by x and y are not modified.

  • x.Equals(a null reference (Nothing in Visual Basic)) returns false.

  See GetHashCode for additional required behaviors pertaining to the Equals method. Implementations of Equals must not throw exceptions. For some kinds of objects, it is desirable to have Equals test for value equality instead of referential equality. Such implementations of Equals return true if the two objects have the same "value", even if they are not the same instance. The type's implementer decides what constitutes an object's "value", but it is typically some or all the data stored in the instance variables of the object. For example, the value of a String is based on the characters of the string; the Equals method of the String class returns true for any two string instances that contain exactly the same characters in the same order. Types that implement IComparable must override Equals. Types that override Equals must also override GetHashCode; otherwise, Hashtable might not work correctly. If your programming language supports operator overloading and if you choose to overload the equality operator for a given type, that type must override the Equals method. Such implementations of the Equals method must return the same results as the equality operator. Following this guideline will help ensure that class library code using Equals (such as ArrayList and Hashtable) behaves in a manner that is consistent with the way the equality operator is used by application code. The following guidelines are for implementing a value type:

  • Consider overriding Equals to gain increased performance over that provided by the default implementation of Equals on ValueType.

  • If you override Equals and the language supports operator overloading, you must overload the equality operator for your value type.

  The following guidelines are for implementing a reference type:

  • Consider overriding Equals on a reference type if the semantics of the type are based on the fact that the type represents some value(s).

  • Most reference types must not overload the equality operator, even if they override Equals. However, if you are implementing a reference type that is intended to , such ashave value semantics a complex number type, you must override the equality operator."

  So All is Crystal Clear why Equals() behaves like this, If this was a bug this should not be written in MSDN that Equals works for Referential Equaltiy,

  So Conclusion is:

  You'll Get:

  Array a1 = new int[]{1,2,3};
  Array a2 = a1;

  a1.Equals(a2);//True

  Becuase both are sharing a reference to the same Value, When you need to do comprison on Value basis then derive from base class and do Override Equals method!

  In last, each Language has its own Semantics, Syntax, Design so you can blame C++ did some work then C# must also do the same, May be there are several reasons that Architect did think at that time what you are not seeing right now!

  In C++ all things are Value Types, All classes, Structues etc, You needed to explicitly pass reference of an object to some object using ref key word or address operator that made C++ to check equality to be the same because all things were value types and value comparison was enough.

  Here is a different sceniro, there are 2 types of object in C# 1) Value Types and 2) Reference type.

  Treating both with the same Equals Method is just like You combine Humans and Animals .

  I hope this give you pretty much clear sence about all this!

  Best Regards,

  
  
  

• Shaka

  But that's quiet deferent from c++'s stl.

  I believe it that stl is the best choice for a collection framework.also ,c#'s collections namespace should learn form stl. But in C#,Many method that should be implemented haven't been worked on well.

  I'm sure there are many c++ user who's frustrated when they found the problems of c#. I also believe a programming library should be easy to use. and should do it's best to make less misunderstand. C# really makes many missunderstand. If the ms doesn't fix these bugs,I belive it that C# will be used by ms's staff only.

  Do you agree

  Also,c#'s backward compatibility will cause bugs too. Eg: If someone use the equal as the referenceEqual,then,when one day, a ms's great programmer,want to change the bad scene, corrected the equals method. The codes the user write will fail with strange problems.

  
  

• Mark The Archer Evans

  I think the vast majority of people would think that C# is much clearer than C++; positive choices were made not to include things like macros and complex preprocessor directives to help ensure this.

  You believe the behaviours you don't like are a 'bug' but they aren't. This is the way some of the worlds experts on class and language design have chosen to build it. There is very little in the framework that slipped in by mistake, and nothing in the C# language. As for being used only by Microsoft's staff... er, well in fact you could not be more wrong. It is already just about the most widely used language in the world.

  In some ways it is a more limited language than C++ and this is quite intentional, to make it simpler, quicker to develop in, and clearer. I've been programming in C# for over 5 years now and have found it to be incredibly powerful and flexible for almost every case. If you don't like C#, then you can always use C++/CLR which gives you a lot of the benefits but with C++ syntax, or just stick with C++. Nobody is twisting your arm to change.

  
  
  

• pu132

  I don't see that there is any great confusion around the Equals method. Typically value types will override it and implement their own version, and reference types won't, because value types use value equality and reference types use reference equality. What's confusing about that
  
  

• Bjørnar Sundsbø

  But the c#'s IDE is very,very good.
  
  

• London Calling

  // bug1. Array a1=new int[]{1,2,3}; Array a2=new int[]{1,2,3}; // a1.Equals(a2)==false;

  I 'd dispute that is a bug. Actually, It's a design choice. Consider for a minute if that comparison was true. If so, should this also be true :

  Array a1=new int[]{1,2,3}; Array a2=new int[]{1,3,2}; bool b = a1.Equals(a2)

  In a collection of integers, order is frequently unimportant. Shouldn't those that don't care about order be able to use == also

  Furthermore, for System.Array to define == as "contents equal" than it must be limited to storing IComparible objects.

  
  
  

• ccyt

  Ok,maybe my bug1 is not a but,how about this:
  
  BitArray a1=new BitArray(5);
  BitArray a2=new BitArray(5);
  
  a1[3]=a2[3]=true;
  
  bool b= a1.Equals(a2);
  
  here b is false too, but if you say that's not buged, No one would agree!!
  
  I'm sure at least a method for comparing two BitArray should be supplied,Or else C# is too bad to C++.
  
  

• Coggsa

  By the way, you're confusing C# the language with the .Net common runtime. The behaviour of all these collections is defined by the .Net common runtime, not by the C# language.
  
  
  
• Object.Equals causes lots of mistakes.