Qualcuno può spiegare questo strano comportamento con float firmati in C #?

Ecco l'esempio con i commenti:

class Program
{
    // first version of structure
    public struct D1
    {
        public double d;
        public int f;
    }

    // during some changes in code then we got D2 from D1
    // Field f type became double while it was int before
    public struct D2 
    {
        public double d;
        public double f;
    }

    static void Main(string[] args)
    {
        // Scenario with the first version
        D1 a = new D1();
        D1 b = new D1();
        a.f = b.f = 1;
        a.d = 0.0;
        b.d = -0.0;
        bool r1 = a.Equals(b); // gives true, all is ok

        // The same scenario with the new one
        D2 c = new D2();
        D2 d = new D2();
        c.f = d.f = 1;
        c.d = 0.0;
        d.d = -0.0;
        bool r2 = c.Equals(d); // false! this is not the expected result        
    }
}

Allora, cosa ne pensi di questo?

Il bug è nelle seguenti due righe di System.ValueType: (Sono entrato nella fonte di riferimento)

if (CanCompareBits(this)) 
    return FastEqualsCheck(thisObj, obj);

(Entrambi i metodi sono [MethodImpl(MethodImplOptions.InternalCall)])

Quando tutti i campi hanno una larghezza di 8 byte, CanCompareBitsrestituisce erroneamente true, risultando in un confronto bit a bit di due valori diversi, ma semanticamente identici.

Quando almeno un campo non ha una larghezza di 8 byte, CanCompareBitsrestituisce false e il codice continua a utilizzare la riflessione per scorrere i campi e chiamare Equalsciascun valore, che considera correttamente -0.0uguale a 0.0.

Ecco la fonte di CanCompareBitsSSCLI:

FCIMPL1(FC_BOOL_RET, ValueTypeHelper::CanCompareBits, Object* obj)
{
    WRAPPER_CONTRACT;
    STATIC_CONTRACT_SO_TOLERANT;

    _ASSERTE(obj != NULL);
    MethodTable* mt = obj->GetMethodTable();
    FC_RETURN_BOOL(!mt->ContainsPointers() && !mt->IsNotTightlyPacked());
}
FCIMPLEND

Ho trovato la risposta su http://blogs.msdn.com/xiangfan/archive/2008/09/01/magic-behind-valuetype-equals.aspx .

Il pezzo principale è il commento alla fonte CanCompareBits, che ValueType.Equalsusa per determinare se usare il memcmpconfronto stile:

Il commento di CanCompareBits dice "Restituisce vero se il tipo di valore non contiene puntatore ed è strettamente compresso". E FastEqualsCheck usa "memcmp" per accelerare il confronto.

L'autore prosegue affermando esattamente il problema descritto dall'OP:

Immagina di avere una struttura che contiene solo un galleggiante. Cosa accadrà se uno contiene +0,0 e l'altro contiene -0,0? Dovrebbero essere uguali, ma la rappresentazione binaria sottostante è diversa. Se annidate un'altra struttura che sovrascrive il metodo Equals, anche quell'ottimizzazione fallirà.

La congettura di Vilx è corretta. Ciò che "CanCompareBits" fa è verificare se il tipo di valore in questione è "compresso" in memoria. Una struttura strettamente compatta viene confrontata semplicemente confrontando i bit binari che compongono la struttura; una struttura vagamente compatta viene confrontata chiamando Equals su tutti i membri.

Questo spiega l'osservazione di SLaks che riprende con strutture che sono tutte doppie; tali strutture sono sempre strettamente imballate.

Sfortunatamente, come abbiamo visto qui, ciò introduce una differenza semantica perché il confronto bit per bit dei doppi e il confronto dei doppi dei doppi danno risultati diversi.

Mezza risposta:

Reflector ci dice che ValueType.Equals()fa qualcosa del genere:

if (CanCompareBits(this))
    return FastEqualsCheck(this, obj);
else
    // Use reflection to step through each member and call .Equals() on each one.

Sfortunatamente entrambi CanCompareBits()e FastEquals()(entrambi i metodi statici) sono extern ( [MethodImpl(MethodImplOptions.InternalCall)]) e non hanno fonti disponibili.

Torniamo a indovinare perché un caso può essere confrontato per bit e l'altro no (forse problemi di allineamento?)

Essa non dà vero per me, con il GMC di Mono 2.4.2.3.

Caso di prova più semplice:

Console.WriteLine("Good: " + new Good().Equals(new Good { d = -.0 }));
Console.WriteLine("Bad: " + new Bad().Equals(new Bad { d = -.0 }));

public struct Good {
    public double d;
    public int f;
}

public struct Bad {
    public double d;
}

EDIT : il bug si verifica anche con float, ma si verifica solo se i campi nella struttura si sommano a un multiplo di 8 byte.

Deve essere correlato un confronto bit per bit, poiché 0.0dovrebbe differire -0.0solo dal bit del segnale.

…Cosa ne pensi di questo?

Sostituisci sempre Equals e GetHashCode sui tipi di valore. Sarà veloce e corretto.

Solo un aggiornamento per questo bug di 10 anni: è stato corretto ( Disclaimer : sono l'autore di questo PR) in .NET Core che sarebbe probabilmente stato rilasciato in .NET Core 2.1.0.

Il post sul blog ha spiegato il bug e come l'ho risolto.

Se fai D2 in questo modo

public struct D2
{
    public double d;
    public double f;
    public string s;
}

è vero.

se lo fai così

public struct D2
{
    public double d;
    public double f;
    public double u;
}

È ancora falso.

i t sembra come se fosse false se l'struct contiene solo doppie.

Deve essere correlato a zero, poiché ha cambiato la linea

dd = -0,0

per:

dd = 0,0

risulta vero il confronto ...