誰かがこの奇妙な動作をC＃の符号付き浮動小数点数で説明できますか？

これはコメント付きの例です：

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        
    }
}

それで、これについてどう思いますか？

バグは次の2行にありSystem.ValueTypeます：（参照ソースに足を踏み入れました）

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

（両方の方法があります[MethodImpl(MethodImplOptions.InternalCall)]）

すべてのフィールドの幅が8バイトのCanCompareBits場合、誤ってtrueが返され、2つの異なる値がビット単位で比較されますが、意味的には同じです。

少なくとも1つのフィールドに広い8つのバイトでない場合、CanCompareBitsfalseを戻し、フィールドをループし、コールに使用する反射のコード進行Equals各値、正しく扱いのため-0.0に等しいとして0.0。

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

答えはhttp://blogs.msdn.com/xiangfan/archive/2008/09/01/magic-behind-valuetype-equals.aspxで見つかりました。

コアピースはのソースコメントでありCanCompareBits、をValueType.Equals使用してmemcmpスタイル比較を使用するかどうかを決定します。

CanCompareBitsのコメントには、「valuetypeにポインターが含まれておらず、密にパックされている場合はtrueを返す」と記載されています。また、FastEqualsCheckは「memcmp」を使用して比較を高速化します。

著者は、OPによって記述された問題を正確に述べ続けます。

フロートのみを含む構造があるとします。一方に+0.0が含まれ、もう一方に-0.0が含まれている場合はどうなりますか？それらは同じである必要がありますが、基礎となるバイナリ表現は異なります。Equalsメソッドをオーバーライドする他の構造をネストすると、その最適化も失敗します。

Vilxの予想は正しい。「CanCompareBits」が行うことは、問題の値の型がメモリに「密にパック」されているかどうかを確認することです。密にパックされた構造体は、構造を構成するバイナリビットを比較するだけで比較されます。疎にパックされた構造は、すべてのメンバーでEqualsを呼び出すことによって比較されます。

これは、すべてダブルの構造体で再現するというSLaksの見解を説明しています。そのような構造体は常に密に詰め込まれています。

残念ながら、ここで見たように、ダブルのビットごとの比較とダブルのEquals比較は異なる結果をもたらすため、セマンティックの違いが生じます。

答えの半分：

リフレクターは、ValueType.Equals()次のようなことをすることを教えてくれます：

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

残念ながらCanCompareBits()とFastEquals()（両方の静的メソッド）はextern（[MethodImpl(MethodImplOptions.InternalCall)]）であり、利用可能なソースがありません。

なぜ1つのケースをビットで比較できるのか、もう1つのケースは比較できないのかを推測することに戻ってください（アライメントの問題か？）

Monoのgmcs 2.4.2.3を使えば、それは私にも当てはまります。

よりシンプルなテストケース：

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;
}

編集：このバグはフロートでも発生しますが、構造体のフィールドの合計が8バイトの倍数になる場合にのみ発生します。

信号ビットのみ0.0が異なるため、ビットごとの比較に関連している必要があります-0.0。

…これについてどう思う？

常に値の型のEqualsとGetHashCodeをオーバーライドします。それは速くて正しいでしょう。

この10年前のバグの単なる更新：.NET Core 2.1.0でおそらくリリースされる.NET Coreで修正されました（免責事項：私はこのPRの作成者です）。

ブログの記事は、バグを説明し、どのように私はそれを修正しました。

このようにD2を作ると

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

それは本当です。

このようにしたら

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

それはまだ誤りです。

私構造体のみがダブルスを保持している場合、それは偽だようにtは思えます。

行を変更するので、ゼロに関連している必要があります

dd = -0.0

に：

dd = 0.0

比較は真になります...