Utilisation de gethashcode pour tester l'égalité dans les égaux de remplacement

Les autres ont raison; Votre opération d'égalité est cassée. Pour illustrer:

public static void Main()
{
    var c1 = new Class1() { A = "apahaa", B = null };
    var c2 = new Class1() { A = "abacaz", B = null };
    Console.WriteLine(c1.Equals(c2));
}

Il y a un cas où l'utilisation de Hashcodes comme une coupe courte sur les comparaisons à l'égalité a du sens.

Considérez le cas où vous construisez une hache ou un hashset. En fait, considérons simplement des hashèsets (les hashables étendent qu'en tenant également une valeur, mais qui n'est pas pertinente).

Il existe différentes approches que l'on peut prendre, mais dans tous, vous avez un petit Nombre de machines à sous les valeurs hachées peuvent être placées et nous prenons l'approche ouverte ou fermée (qui juste pour le plaisir, certaines personnes utilisent le jargon opposé pour les autres); Si nous entrons en collision sur la même fente pour deux objets différents, nous pouvons les stocker dans la même fente (mais avoir une liste liée ou telle pour l'endroit où les objets sont réellement stockés) ou en rééchangeant une fente différente (il y a divers Stratégies pour cela).

Maintenant, avec l'une ou l'autre approche, nous nous éloignons de la complexité O (1) que nous voulons avec une haquetable et vers une complexité O (n). Le risque de ceci est inversement proportionnel au nombre de machines à sous disponibles. Après une certaine taille, nous redimensionnons la haquetable (même si tout était idéal, nous devions finalement faire cela si le nombre d'articles stockés était supérieur au nombre de Slots).

Ré-insertion des éléments sur un redimensionnement dépendra évidemment des codes de hachage. À cause de cela, alors qu'il est rarement logique de mémoise gethascode () dans un objet (il n'est tout simplement pas appelé assez souvent sur la plupart des objets), il est certainement logique de le souvenir dans la table de hachage lui-même (ou peut-être, à mémoter un résultat produit, tel que si vous re-déduisez avec un hachage de Wang / Jenkins afin de réduire les dommages causés par Bad gethashcode () implémentations).

Maintenant, quand on vient insérer notre logique va être quelque chose comme:

1. Obtenez le code de hachage pour objet.
2. Obtenez la fente pour l'objet.
3. Si la fente est vide, placez l'objet dedans et retournez.
4. Si la fente contient un objet égal, nous avons terminé un hashset et avons la position de remplacer la valeur d'une hache. Faites cela et retournez.
5. Essayez la prochaine fente selon la stratégie de collision et revenez au point 3 (redimensionner peut-être si nous nous en bouge trop souvent).

   Donc, dans ce cas, nous devons obtenir le code de hachage avant de comparer pour l'égalité. Nous avons également le code de hachage des objets existants déjà pré-calculés pour permettre le redimensionnement. La combinaison de ces deux faits signifie qu'il est logique de mettre en œuvre notre comparaison du point 4 comme: xxx

   évidemment, l'avantage de cela dépend de la complexité du _cmp .Equals . Si notre type de clé était int , ce serait un déchet total. Si notre type de clé où la chaîne et que nous utilisions des comparaisons d'égalité normalisées de casse-insensibles (de sorte qu'il ne peut même pas être raccourci de longueur), la sauvegarde pourrait bien valoir la peine.

   Mémo-mémoire code de hachage Il est de sens parce qu'ils ne sont pas utilisés assez souvent pour être une victoire de performance, mais les stocker dans le hashset ou la hache elle-même peut avoir un sens.