Definizione dell'operatore "==" per Double

Per qualche motivo stavo entrando di nascosto nel sorgente .NET Framework per la classe Doublee ho scoperto che la dichiarazione di ==è:

public static bool operator ==(Double left, Double right) {
    return left == right;
}

La stessa logica vale per ogni operatore.

• Qual è il punto di tale definizione?
• Come funziona?
• Perché non crea una ricorsione infinita?

In realtà, il compilatore trasformerà l' ==operatore in un ceqcodice IL e l'operatore menzionato non verrà chiamato.

Il motivo per cui l'operatore nel codice sorgente è probabilmente così può essere chiamato da lingue diverse da C # che non lo traducono CEQdirettamente in una chiamata (o tramite la riflessione). Il codice all'interno dell'operatore verrà compilato in un CEQ, quindi non c'è ricorsione infinita.

Infatti, se si chiama l'operatore tramite reflection, è possibile vedere che l'operatore viene chiamato (anziché CEQun'istruzione) e ovviamente non è infinitamente ricorsivo (poiché il programma termina come previsto):

double d1 = 1.1;
double d2 = 2.2;

MethodInfo mi = typeof(Double).GetMethod("op_Equality", BindingFlags.Static | BindingFlags.Public );

bool b = (bool)(mi.Invoke(null, new object[] {d1,d2}));

IL risultante (compilato da LinqPad 4):

IL_0000:  nop         
IL_0001:  ldc.r8      9A 99 99 99 99 99 F1 3F 
IL_000A:  stloc.0     // d1
IL_000B:  ldc.r8      9A 99 99 99 99 99 01 40 
IL_0014:  stloc.1     // d2
IL_0015:  ldtoken     System.Double
IL_001A:  call        System.Type.GetTypeFromHandle
IL_001F:  ldstr       "op_Equality"
IL_0024:  ldc.i4.s    18 
IL_0026:  call        System.Type.GetMethod
IL_002B:  stloc.2     // mi
IL_002C:  ldloc.2     // mi
IL_002D:  ldnull      
IL_002E:  ldc.i4.2    
IL_002F:  newarr      System.Object
IL_0034:  stloc.s     04 // CS$0$0000
IL_0036:  ldloc.s     04 // CS$0$0000
IL_0038:  ldc.i4.0    
IL_0039:  ldloc.0     // d1
IL_003A:  box         System.Double
IL_003F:  stelem.ref  
IL_0040:  ldloc.s     04 // CS$0$0000
IL_0042:  ldc.i4.1    
IL_0043:  ldloc.1     // d2
IL_0044:  box         System.Double
IL_0049:  stelem.ref  
IL_004A:  ldloc.s     04 // CS$0$0000
IL_004C:  callvirt    System.Reflection.MethodBase.Invoke
IL_0051:  unbox.any   System.Boolean
IL_0056:  stloc.3     // b
IL_0057:  ret 

È interessante notare - non esistono gli stessi operatori (sia nel sorgente di riferimento o attraverso la riflessione) per i tipi integrali, solo Single, Double, Decimal, String, e DateTime, che smentisce la mia teoria che esistono per essere chiamato da altre lingue. Ovviamente puoi equiparare due numeri interi in altre lingue senza questi operatori, quindi torniamo alla domanda "perché esistono per double"?

La principale confusione qui è che stai assumendo che tutte le librerie .NET (in questo caso, la Libreria numerica estesa, che non fa parte del BCL) siano scritte in C # standard. Questo non è sempre il caso e lingue diverse hanno regole diverse.

In C # standard, il pezzo di codice che si vede comporterebbe un overflow dello stack, a causa del modo in cui funziona la risoluzione di sovraccarico dell'operatore. Tuttavia, il codice non è in realtà in C # standard - utilizza fondamentalmente funzionalità non documentate del compilatore C #. Invece di chiamare l'operatore, emette questo codice:

ldarg.0
ldarg.1
ceq
ret

Questo è tutto :) Non esiste un codice C # equivalente al 100% - questo semplicemente non è possibile in C # con il tuo tipo.

Anche in questo caso, l'operatore effettivo non viene utilizzato durante la compilazione del codice C #: il compilatore esegue una serie di ottimizzazioni, come in questo caso, in cui sostituisce la op_Equalitychiamata con il semplice ceq. Ancora una volta, non puoi replicarlo nella tua DoubleExstruttura: è la magia del compilatore.

Questa non è certamente una situazione unica in .NET - c'è un sacco di codice che non è valido, C # standard. I motivi sono di solito (a) hack del compilatore e (b) un linguaggio diverso, con gli hack dispari (c) di runtime (ti sto guardando Nullable!!).

Poiché il compilatore Roslyn C # è oepn source, posso effettivamente indicarti il ​​punto in cui viene decisa la risoluzione del sovraccarico:

Il luogo in cui vengono risolti tutti gli operatori binari

Le "scorciatoie" per operatori intrinseci

Quando guardi le scorciatoie, vedrai che l'uguaglianza tra doppio e doppio risulta nell'operatore intrinseco doppio, mai nell'operatore effettivo ==definito sul tipo. Il sistema di tipi .NET deve fingere che Doublesia un tipo come un altro, ma C # no - doubleè una primitiva in C #.

La fonte dei tipi primitivi può essere fonte di confusione. Hai visto la prima riga della Doublestruttura?

Normalmente non è possibile definire una struttura ricorsiva come questa:

public struct Double : IComparable, IFormattable, IConvertible
        , IComparable<Double>, IEquatable<Double>
{
    internal double m_value; // Self-recursion with endless loop?
    // ...
}

I tipi primitivi hanno il loro supporto nativo anche in CIL. Normalmente non vengono trattati come tipi orientati agli oggetti. Un doppio è solo un valore a 64 bit se viene utilizzato come float64in CIL. Tuttavia, se viene gestito come un normale tipo .NET, contiene un valore effettivo e contiene metodi come qualsiasi altro tipo.

Quindi quello che vedi qui è la stessa situazione per gli operatori. Normalmente se si utilizza direttamente il tipo doppio tipo, non verrà mai chiamato. A proposito, la sua fonte è simile a questa in CIL:

.method public hidebysig specialname static bool op_Equality(float64 left, float64 right) cil managed
{
    .custom instance void System.Runtime.Versioning.NonVersionableAttribute::.ctor()
    .custom instance void __DynamicallyInvokableAttribute::.ctor()
    .maxstack 8
    L_0000: ldarg.0
    L_0001: ldarg.1
    L_0002: ceq
    L_0004: ret
}

Come puoi vedere, non esiste un loop infinito (lo ceqstrumento viene utilizzato invece di chiamare il System.Double::op_Equality). Quindi quando un doppio viene trattato come un oggetto, verrà chiamato il metodo dell'operatore, che alla fine lo gestirà come il float64tipo primitivo a livello CIL.

Ho dato un'occhiata al CIL con JustDecompile. L'interno ==viene tradotto nel ceq CIL codice op. In altre parole, è l'uguaglianza CLR primitiva.

Ero curioso di vedere se il compilatore C # avrebbe fatto riferimento ceqo l' ==operatore quando avrebbe confrontato due valori doppi. Nell'esempio banale che ho trovato (sotto), ha usatoceq .

Questo programma:

void Main()
{
    double x = 1;
    double y = 2;

    if (x == y)
        Console.WriteLine("Something bad happened!");
    else
        Console.WriteLine("All is right with the world");
}

genera il seguente CIL (notare l'istruzione con l'etichetta IL_0017):

IL_0000:  nop
IL_0001:  ldc.r8      00 00 00 00 00 00 F0 3F
IL_000A:  stloc.0     // x
IL_000B:  ldc.r8      00 00 00 00 00 00 00 40
IL_0014:  stloc.1     // y
IL_0015:  ldloc.0     // x
IL_0016:  ldloc.1     // y
IL_0017:  ceq
IL_0019:  stloc.2
IL_001A:  ldloc.2
IL_001B:  brfalse.s   IL_002A
IL_001D:  ldstr       "Something bad happened!"
IL_0022:  call        System.Console.WriteLine
IL_0027:  nop
IL_0028:  br.s        IL_0035
IL_002A:  ldstr       "All is right with the world"
IL_002F:  call        System.Console.WriteLine
IL_0034:  nop
IL_0035:  ret

Come indicato nella documentazione Microsoft per lo spazio dei nomi System.Runtime.Versioning: i tipi trovati in questo spazio dei nomi sono destinati all'uso in .NET Framework e non per le applicazioni utente. Lo spazio dei nomi System.Runtime.Versioning contiene tipi avanzati che supportano il controllo delle versioni in implementazioni affiancate di .NET Framework.