Alles begann mit einer Trickfrage, die mir jemand gestellt hat. (Es wird im Buch erwähnt - C # auf den Punkt gebracht.) Hier ist der Kern der Sache.

Double a = Double.NaN;
Console.WriteLine(a == a); // => false
Console.WriteLine(a.Equals(a)); // => true

Das Obige scheint nicht richtig zu sein. a sollte immer == für sich sein (Referenzgleichheit) und beide sollten konsistent sein.

Scheint, als würde Double den Operator == überladen. Bestätigt durch Reflektor wie folgt:

[__DynamicallyInvokable]
public static bool operator ==(double left, double right)
{
    return (left == right);
}

Seltsam, dass rekursiv aussieht und das NaN-spezifische Verhalten nicht erwähnt wird. Warum gibt es dann falsch zurück?

Also füge ich etwas mehr Code hinzu, um zu unterscheiden

var x = "abc";
var y = "xyz";
Console.WriteLine(x == y); // => false

Jetzt sehe ich

    L_0001: ldc.r8 NaN
    L_000a: stloc.0 
    L_000b: ldloc.0 
    L_000c: ldloc.0 
    L_000d: ceq 
    L_000f: call void [mscorlib]System.Console::WriteLine(bool)
    L_0014: nop 
    L_0015: ldloca.s a
    L_0017: ldloc.0 
    L_0018: call instance bool [mscorlib]System.Double::Equals(float64)
    L_001d: call void [mscorlib]System.Console::WriteLine(bool)
    L_0022: nop 
    L_0023: ldstr "abc"
    L_0028: stloc.1 
    L_0029: ldstr "xyz"
    L_002e: stloc.2 
    L_002f: ldloc.1 
    L_0030: ldloc.2 
    L_0031: call bool [mscorlib]System.String::op_Equality(string, string)
    L_0036: call void [mscorlib]System.Console::WriteLine(bool)

Bei Doppelten wird der Operatoraufruf == in a übersetztceq IL-OpcodeWobei Zeichenfolgen in System.String :: op_Equality (Zeichenfolge, Zeichenfolge) übersetzt werden.

Sicher genug dasDokumentation fürceq Gibt an, dass es für Gleitkommazahlen und NaN in Sonderfällen geschrieben ist. Dies erklärt die Beobachtungen.

Fragen:

Warum ist op_Equality auf Double definiert? (Und die Implementierung berücksichtigt nicht das NaN-spezifische Verhalten.)Wann wird es aufgerufen?