Warum ist das so?
17m.GetHashCode() == 17d.GetHashCode()
(m = dezimal, d = doppelt)
Zusätzlich wie erwartet
17f.GetHashCode() != 17d.GetHashCode()
(f = schweben)
Dies scheint sowohl für net3.5 als auch für net4.0 zu gelten.
Wie ich verstehe, sind die internen Bitdarstellungen dieser Typen ziemlich unterschiedlich. Wie kommt es also, dass die Hashcodes von dezimal und double für gleiche Initialisierungswerte gleich sind? Wird vor der Hash-Berechnung etwas umgesetzt?
Ich habe festgestellt, dass der Quellcode für Double.GetHashCode() dies ist:
Ich habe überprüft, dass dieser Code den gewünschten Wert zurückgibt. Aber ich habe den Quellcode für Decimal.GetHashCode() nicht gefunden. Ich habe versucht, Methode
Dies entsprach jedoch nicht den gewünschten Ergebnissen (es gab den Hashwert zurück, der dem int -Typ entspricht, was auch in Anbetracht der internes Layout von Dezimal ). Daher ist mir die Implementierung von Decimal.GetHashCode() momentan unbekannt.
Die Decimal.GetHashCode () -Methode ist in der CLR implementiert. Sie können einen Blick auf die mögliche Implementierung aus dem SSCLI20-Quellcode clr / vm / comdecimal.cpp:
werfen %Vor%Dies ist ansonsten das genaue Äquivalent der Double.GetHashCode () Implementierung in C # aber in C ++ geschrieben, so dass eine Übereinstimmung nicht unerwartet ist. VarR8FromDec () ist eine COM-Automatisierung-Hilfsfunktion, die ein COM DECIMAL zu verdoppeln.
Natürlich nie ist auf eine solche Übereinstimmung angewiesen.
UPDATE: Es sieht immer noch genauso aus, da die CLR Open-Source ist, sichtbar in diese Github-Datei . Eine Falte ist, dass VarR8FromDec () eine Windows-Funktion ist, die in Linux oder OSX nicht verfügbar ist, sie war im PAL neu implementiert .
Tags und Links .net double decimal gethashcode