Was könnte der Zweck der Tilde in diesem Codeblock sein?
%Vor%^ Operator (C # -Referenz) Visual Studio 2010 Binäre ^ Operatoren sind für die Integraltypen und bool vordefiniert. Für ganzzahlige Typen berechnet ^ das bitweise Exklusiv-ODER seiner Operanden. Für bool-Operanden berechnet ^ das logische Exklusiv-Oder seiner Operanden; das heißt, das Ergebnis ist wahr, wenn und nur wenn genau einer seiner Operanden wahr ist.
~ Operator (C # -Referenz) Visual Studio 2010 Der Operator ~ führt an seinem Operanden eine bitweise Komplementoperation aus, die jedes Bit umkehrt. Bitweise Komplementoperatoren sind für int, uint, long und ulong vordefiniert.
Der Operator ~ (Tilde) führt ein bitweises Komplement für seinen einzelnen ganzzahligen Operanden aus. (Der ~ Operator ist daher ein unärer Operator, wie! Und die unary -, & amp; und * Operatoren.) Eine Zahl zu ergänzen bedeutet, alle 0 Bits auf 1 und alle 1en auf 0 zu setzen
Was wäre ein Grund, warum es in diesem Zusammenhang verwendet würde (anstatt es einfach auszuschließen)?
Es ist einfach eine Möglichkeit, einen Hash-Code zu generieren. Ich bin kein großer Fan von XORs in Hash-Codes, es sei denn, Sie möchten etwas, das unabhängig von der Reihenfolge ist, aber es ist eine vernünftige Methode, um Bits auf halbwegs willkürliche, aber wiederholbare Weise zu spiegeln.
Grundsätzlich haben Sie hier zwei 32-Bit-Werte, die Sie in irgendeiner Form kombinieren müssen, um einen weiteren 32-Bit-Wert zu erstellen. Der Code konnte einfach die Werte zusammen XORed ohne irgendein bitweises Komplement:
%Vor% ... aber das würde immer Null für Fälle geben, wo ElementId.Id == DimensionId.Id , was wahrscheinlich nicht ideal ist. Auf der anderen Seite enden wir nun immer mit -1, wenn die beiden IDs identisch sind, wie in den Kommentaren erwähnt (doh!). Auf der anderen Seite macht es das Paar {6, 4} einen anderen Hash-Code als {4, 6}, während ein einfaches XOR nicht ... es macht die Reihenfolge wichtig, mit anderen Worten. Auch dies könnte wichtig sein, wenn Ihre echten Bezeichner wahrscheinlich aus einem relativ kleinen Pool stammen.
Das XOR selbst stellt sicher, dass eine Änderung des beliebigen Bits in entweder ID den endgültigen Hashcode beeinflusst.
Persönlich folge ich normalerweise Josh Blochs Muster aus effektivem Java, z. B.
%Vor%... aber das liegt nur an einigen Eigenschaften von hashing 1 , und es macht die Implementierung, die Sie gezeigt haben, in keiner Hinsicht "falsch".
>1 Es scheint ziemlich gut zu funktionieren, verschiedene Werte in einer Reihe von allgemeinen Szenarien zu erzeugen. Offensichtlich kann es Hash-Kollisionen nicht verhindern, aber wenn Ihre IDs tatsächlich aus einer Sequenz von 1, 2, 3 generiert werden ... dann wird dies bei realen Kollisionen, die ein XOR sind, besser. Ich habe eine Webseite gesehen, die diesen Ansatz analysiert und welche Zahlen gut funktionieren usw., aber ich kann mich nicht erinnern wo.
Tags und Links c#