Implémentation par défaut pour Object.GetHashCode ()

Comment l'implémentation par défaut pour GetHashCode() ? Et gère-t-il suffisamment et efficacement les structures, les classes, les tableaux, etc.?

J'essaie de décider dans quels cas je dois emballer le mien et dans quels cas je peux compter en toute sécurité sur l'implémentation par défaut pour bien faire. Je ne veux pas réinventer la roue, si possible.

namespace System {
    public class Object {
        [MethodImpl(MethodImplOptions.InternalCall)]
        internal static extern int InternalGetHashCode(object obj);

        public virtual int GetHashCode() {
            return InternalGetHashCode(this);
        }
    }
}

InternalGetHashCode est mappé à une fonction ObjectNative :: GetHashCode dans le CLR, qui ressemble à ceci:

FCIMPL1(INT32, ObjectNative::GetHashCode, Object* obj) {  
    CONTRACTL  
    {  
        THROWS;  
        DISABLED(GC_NOTRIGGER);  
        INJECT_FAULT(FCThrow(kOutOfMemoryException););  
        MODE_COOPERATIVE;  
        SO_TOLERANT;  
    }  
    CONTRACTL_END;  

    VALIDATEOBJECTREF(obj);  

    DWORD idx = 0;  

    if (obj == 0)  
        return 0;  

    OBJECTREF objRef(obj);  

    HELPER_METHOD_FRAME_BEGIN_RET_1(objRef);        // Set up a frame  

    idx = GetHashCodeEx(OBJECTREFToObject(objRef));  

    HELPER_METHOD_FRAME_END();  

    return idx;  
}  
FCIMPLEND

L'implémentation complète de GetHashCodeEx est assez volumineuse, il est donc plus facile de simplement créer un lien vers le code source C ++ .

Pour une classe, les valeurs par défaut sont essentiellement l'égalité de référence, et c'est généralement bien. Si vous écrivez une structure, il est plus courant de surcharger l'égalité (notamment pour éviter la boxe), mais il est très rare d'écrire une structure de toute façon!

Lorsque vous remplacez l'égalité, vous devriez toujours avoir une correspondance Equals()et GetHashCode()(c'est-à-dire pour deux valeurs, si Equals()retourne true, elles doivent retourner le même code de hachage, mais l'inverse n'est pas obligatoire) - et il est courant de fournir également des opérateurs ==/ !=, et souvent de mettre en œuvre IEquatable<T>aussi.

Pour générer le code de hachage, il est courant d'utiliser une somme pondérée, car cela évite les collisions sur des valeurs appariées - par exemple, pour un hachage de base à 2 champs:

unchecked // disable overflow, for the unlikely possibility that you
{         // are compiling with overflow-checking enabled
    int hash = 27;
    hash = (13 * hash) + field1.GetHashCode();
    hash = (13 * hash) + field2.GetHashCode();
    return hash;
}

Cela présente l'avantage que:

• le hachage de {1,2} n'est pas le même que le hachage de {2,1}
• le hachage de {1,1} n'est pas le même que le hachage de {2,2}

etc - ce qui peut être courant si vous utilisez simplement une somme non pondérée, ou xor ( ^), etc.

La documentation de la GetHashCodeméthode pour Object indique que "l'implémentation par défaut de cette méthode ne doit pas être utilisée comme identificateur d'objet unique à des fins de hachage". et celui de ValueType indique "Si vous appelez la méthode GetHashCode du type dérivé, la valeur de retour n'est probablement pas adaptée à une utilisation comme clé dans une table de hachage.".

Les types de données de base comme byte, short, int, long, charet stringmettre en œuvre une bonne méthode GetHashCode. Certaines autres classes et structures, comme Pointpar exemple, implémentent unGetHashCode méthode qui peut ou non convenir à vos besoins spécifiques. Il vous suffit de l'essayer pour voir si c'est assez bon.

La documentation de chaque classe ou structure peut vous dire si elle remplace ou non l'implémentation par défaut. S'il ne le remplace pas, vous devez utiliser votre propre implémentation. Pour toutes les classes ou structures que vous créez vous-même où vous devez utiliser la GetHashCodeméthode, vous devez créer votre propre implémentation qui utilise les membres appropriés pour calculer le code de hachage.

Comme je n'ai pas trouvé de réponse expliquant pourquoi nous devrions remplacer GetHashCodeet Equalspour les structures personnalisées et pourquoi l'implémentation par défaut "n'est pas susceptible d'être utilisée comme clé dans une table de hachage", je vais laisser un lien vers ce blog post , ce qui explique pourquoi avec un exemple concret d'un problème survenu.

Je recommande de lire l'intégralité du message, mais voici un résumé (soulignement et clarifications ajoutés).

Raison pour laquelle le hachage par défaut pour les structures est lent et pas très bon:

La façon dont le CLR est conçu, chaque appel à un membre défini dans System.ValueTypeou System.Enumtypes [peut] provoquer une allocation de boxe [...]

Un réalisateur d'une fonction de hachage est confronté à un dilemme: faire une bonne distribution de la fonction de hachage ou la rendre rapide. Dans certains cas, il est possible de les atteindre tous les deux, mais il est difficile de le faire de manière générique dansValueType.GetHashCode .

La fonction de hachage canonique d'une structure "combine" les codes de hachage de tous les champs. Mais le seul moyen d'obtenir un code de hachage d'un champ dans une ValueTypeméthode est d' utiliser la réflexion . Ainsi, les auteurs du CLR ont décidé d'échanger de la vitesse sur la distribution et la GetHashCodeversion par défaut renvoie simplement un code de hachage d'un premier champ non nul et le «munit» d'un identifiant de type [...] C'est un comportement raisonnable sauf si ce n'est pas le cas . Par exemple, si vous êtes assez malchanceux et que le premier champ de votre structure a la même valeur pour la plupart des instances, alors une fonction de hachage fournira le même résultat tout le temps. Et, comme vous pouvez l'imaginer, cela aura un impact considérable sur les performances si ces instances sont stockées dans un jeu de hachage ou une table de hachage.

[...] La mise en œuvre basée sur la réflexion est lente . Très lent.

[...] Les deux ValueType.Equalset ValueType.GetHashCodeont une optimisation spéciale. Si un type n'a pas de "pointeurs" et est correctement compressé [...] alors des versions plus optimales sont utilisées: GetHashCodeitère sur une instance et XORs blocs de 4 octets et la Equalsméthode compare deux instances en utilisant memcmp. [...] Mais l'optimisation est très délicate. Premièrement, il est difficile de savoir quand l'optimisation est activée [...] Deuxièmement, une comparaison de mémoire ne vous donnera pas forcément les bons résultats . Voici un exemple simple: [...] -0.0et +0.0sont égaux mais ont des représentations binaires différentes.

Problème du monde réel décrit dans l'article:

private readonly HashSet<(ErrorLocation, int)> _locationsWithHitCount;
readonly struct ErrorLocation
{
    // Empty almost all the time
    public string OptionalDescription { get; }
    public string Path { get; }
    public int Position { get; }
}

Nous avons utilisé un tuple contenant une structure personnalisée avec une implémentation d'égalité par défaut. Et malheureusement, la structure avait un premier champ facultatif qui était presque toujours égal à [chaîne vide] . Les performances étaient correctes jusqu'à ce que le nombre d'éléments de l'ensemble augmente de manière significative, provoquant un réel problème de performances, prenant quelques minutes pour initialiser une collection avec des dizaines de milliers d'éléments.

Donc, pour répondre à la question "dans quels cas je devrais emballer le mien et dans quels cas je peux compter en toute sécurité sur l'implémentation par défaut", au moins dans le cas des structures , vous devez surcharger Equalset GetHashCodechaque fois que votre structure personnalisée peut être utilisée comme un entrez une table de hachage ou Dictionary.
Je recommanderais également la mise IEquatable<T>en œuvre dans ce cas, pour éviter la boxe.

Comme le disent les autres réponses, si vous écrivez une classe , le hachage par défaut utilisant l'égalité de référence est généralement correct, donc je ne me dérangerais pas dans ce cas, à moins que vous n'ayez besoin de remplacer Equals(alors vous devrez remplacer en GetHashCodeconséquence).

De manière générale, si vous remplacez Equals, vous souhaitez remplacer GetHashCode. La raison en est que les deux sont utilisés pour comparer l'égalité de votre classe / structure.

Equals est utilisé lors de la vérification de Foo A, B;

si (A == B)

Puisque nous savons que le pointeur n'est pas susceptible de correspondre, nous pouvons comparer les membres internes.

Equals(obj o)
{
    if (o == null) return false;
    MyType Foo = o as MyType;
    if (Foo == null) return false;
    if (Foo.Prop1 != this.Prop1) return false;

    return Foo.Prop2 == this.Prop2;
}

GetHashCode est généralement utilisé par les tables de hachage. Le hashcode généré par votre classe doit toujours être le même pour une classe donnant l'état.

Je fais généralement,

GetHashCode()
{
    int HashCode = this.GetType().ToString().GetHashCode();
    HashCode ^= this.Prop1.GetHashCode();
    etc.

    return HashCode;
}

Certains diront que le hashcode ne devrait être calculé qu'une fois par durée de vie d'objet, mais je ne suis pas d'accord avec cela (et je me trompe probablement).

En utilisant l'implémentation par défaut fournie par object, à moins que vous n'ayez la même référence à l'une de vos classes, elles ne seront pas égales l'une à l'autre. En remplaçant Equals et GetHashCode, vous pouvez signaler l'égalité basée sur des valeurs internes plutôt que sur la référence des objets.

Si vous avez uniquement affaire à des POCO, vous pouvez utiliser cet utilitaire pour vous simplifier quelque peu la vie:

var hash = HashCodeUtil.GetHashCode(
           poco.Field1,
           poco.Field2,
           ...,
           poco.FieldN);

...

public static class HashCodeUtil
{
    public static int GetHashCode(params object[] objects)
    {
        int hash = 13;

        foreach (var obj in objects)
        {
            hash = (hash * 7) + (!ReferenceEquals(null, obj) ? obj.GetHashCode() : 0);
        }

        return hash;
    }
}