Bad implementation of SortedSetEqualityComparer<T>.

    General discussion

  • 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_
    Monday, October 10, 2011 8:22 AM

All replies

  • 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();






    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.

    Thursday, October 13, 2011 2:47 AM
  • 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:

    Viacheslav Ivanov aka _FRED_
    Thursday, October 13, 2011 3:41 AM