Bad implementation of SortedSetEqualityComparer<T>.

Question

In SortedSetEqualityComparer<T> class (defined within SortedSet<>) I see a next lines:

// Equals method for the comparer itself. 
public override bool Equals(Object obj) { 
    SortedSetEqualityComparer<T> comparer = obj as SortedSetEqualityComparer<T>;
    if (comparer == null) { 
        return false;
    }
    return (this.comparer == comparer.comparer);
} 

public override int GetHashCode() { 
    return comparer.GetHashCode() ^ e_comparer.GetHashCode(); 
}

And I have a two questions:

1) Why in an Equals method comparers compared by reference and Equals(this.comparer, comparer.comparer) does not used? It can be helpful in a custom comparers logic (for example, SortedSet of SortedSets).

2) Why in a GetHashCode() used both "comparer" and "e_comparer" and in an Equals only "comparer" used? It conflicted with a "Notes to Implementers" for an Object::Equals method.

---

Viacheslav Ivanov aka _FRED_

Answer 1

Well, I think it is by design.

You can read the two documents:

Object.Equals Method (Object)

Object.Equals Method (Object, Object)

Equals method can be override. The Equals(Object) method is implemented in the class. When you create a instance of this class, the method would have a hidden parameter --this.comparer. You just need to pass another instance of this class as parameter to compare them:

 

ClassA  a1=new ClassA();

ClassA a2=new ClassA();

a1.Equals(a2);

a2.Equals(a1);

Object.Equals(a1,a2);

 

 

---

Paul Zhou [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 2

What is "By design"? Are both of my questions?

1) Are you see, that we can not create a correct SortedSet of SortedSets is some cases?

2) Are you see, that implementation of Equals does not following the "Notes to Implementers" for an Object::Equals method (We can have a varied hashcodes for to comparers, that have Object::Equals(c1, c2) is true)? This is by design?

May be, you can a describe a "desigin" do you mean? What kind of "design" allows this things? I can not see.

For example, a comparer, created by HashSet<>::CreateSetComparer has an invalid implementation too: https://connect.microsoft.com/VisualStudio/feedback/details/691427.

---

Viacheslav Ivanov aka _FRED_