Partizan, есть предположение, что для D1 метод CanCompareBits возвращает false по причине наличия поля типа int и сравнение ведется не побитиво, а по полям. А в D2 выполняется FastEqualsCheck, который возвращает false. 

ммм...странно..очень странно...каким образом поле типа int может повлиять на возможность побитового сравнения?

Копание в инете дало варианта - CanCompareBits не проходит если в структуре есть пропуски, которые забиваются случайными данными. Возможно то как раз тот случай.

http://blogs.msdn.com/xiangfan/archive/200...ype-equals.aspx

мде...вот и ответ на вопрос...

Magic????

- Magic!

Если я все правельно понял , то получается следующее :
1. В памяти +0 и -0 хранятся по разному , для вещественных типов
2. Разработчики BCL определили Equals для вещественных чисел таким образом , что +0 -0 равные числа. Обоснование этого - для человека это действительно одинаковые числа. В общем то так оно и должно быть.
3. Для типов значений метод Equals без переопределения исходя из каких то своих соображений то выдает результат на основе побитового сравнения обьектов , то сравнивая поля класса.
4. Из-за переопределённого на уровне double Equals метода мы получаем разные результаты при разных способах сравнения обьектов.

Просто разработчики BCL видемо забыли такой вариант рассмотреть. Не знаю , по идее надо куда то писать в M$ с просьбой профиксить.

Интересно все таки на основе чего выбирается метода сравнения валуе типов.....
Кто нибудь проверял это в CLR 1.x. вдруг там подругому....

Это сообщение отредактировал(а) nikitao - 7.10.2008, 19:53

Проверяли в жабе...в обоих случаях она выдаёт false

А ты добавь в структуру D2 поле типа int, можешь даже не делать с ним ничего, и посмотри результат.

diadiavova, собственно в результате никто не сомневается 

Прикольный баг. Надо всё-таки самим определять Equals, а не надеятся на компилятор.


Извиняюсь, а как такое можно проверить в Java, если там в принципе нет никаких value type?

Дрон, =) Не знал, не спец по жабе) я ж говорю, разведка доложила)

Честно говоря всю тему поленился читать, каюсь. 
Выскажу предположение, надеюсь меня за это не побьют.
Когда в структуре числовые поля одного типа, их сравнение ведётся по упрощённому алгоритму, просто сравниваются как double и всё. А если поля разнотипные, то сначала проверяется тип, причём проверка осуществляется по значению. При проверке чисел 0 и -0 они(по значению) типизируются как целочисленные и логика перенаправляется в ту ветвь, где сравниваются целые числа. А при сравнении их как целых результат очевиден. 
Так что, возможно это не ошибка, а просто ради экономии ресурсов упростили.

здравая мысль.   
Впрочем это как раз будет следованием .NET Guidelines.. Все сравниваемые пользовательские типы должны иметь собственную реализацию IEquatable<T>.