По какой причине классы Image и Bitmap не реализуют собственную логику равенства / хэш-кода?

Question

Из документации MSDN кажется, что и GetHashCode (), и Equals () не были переопределены в Bitmap. Ни один из них не был переопределен в образе. Таким образом, оба класса используют версию объекта, они просто сравнивают ссылки. Я не был слишком убежден, поэтому я решил запустить Reflector, чтобы проверить это. Похоже, MSDN является правильным в этом отношении.

Итак, есть ли какая-то особая причина, по которой парни из MS не будут реализовывать «логику сравнения», по крайней мере, для класса Bitmap? Я считаю, что это довольно приемлемо для Image, поскольку это абстрактный класс, но не так много для класса Bitmap. Я вижу, что во многих ситуациях вычисление хеш-кода может быть дорогостоящей операцией, но было бы хорошо, если бы он использовал какое-то кэширование.

При желании сравнить 2 растровых изображения, придется ли мне прибегать к необходимости бегать по всему изображению, сравнивая каждый из его пикселей?

Спасибо

Answer 1

Давайте перевернем этот вопрос;Есть ли какая-то особая причина, по которой они могли бы реализовать такую ​​вещь?

С одной стороны, было бы очень и очень дорого вычислять хеш, делая его почти бесполезным для хеш-таблиц иподобное, аналогичное, похожее.Просто попытайтесь представить, что делаете это на большом количестве растровых изображений 1920x1200;выполнение даже один раз для каждого растрового изображения приведет к замедлению работы программы.Я ожидаю, что в 9 случаях из 10, когда кто-то должен сравнивать два растровых изображения, ему нужно равенство ссылок, а не равенство значений по пикселям.

И то, на что вы ссылаетесь в своем вопросе, не ленивооценка, это кеширование.Кэширование - это нетривиальная функция для реализации, и каждая функция начинается с минус 100 баллов .

Учитывая все это, я отвечу на это, что методы не переопределяютсяпотому что переопределенные версии не будут особенно полезны для многих людей по сравнению со стоимостью реализации и поддержки такой функции.Если вы действительно хотите попиксельное сравнение (или контрольные суммы, или подобные вещи), то вы всегда можете реализовать их самостоятельно в 10 строк или около того.

Answer 2

Изображения и растровые изображения обычно являются изменяемыми ссылочными типами. Изменяемые ссылочные типы должны никогда переопределять Equals(Object), поскольку Equals(Object) не должен сообщать о том, что два объекта оказались в одинаковом состоянии во время его вызова, а скорее о том, будут ли два объекта всегда и навсегда эквивалент. Даже если два изменчивых объекта оказываются в одном и том же состоянии в одно и то же время, это никоим образом не означает, что они всегда будут это делать.

Answer 3

Когда выполняется встроенное сравнение растровых изображений, которое MS не реализовала, необходимо будет сравнить каждое из пикселей.Конечно, MS, вероятно, сделает сравнение памяти (возможно, в небезопасном блоке), но вы можете сделать то же самое, если хотите.Несмотря на это, сравнение двух растровых изображений всегда будет дорогостоящим.И вы не можете полагаться на оба хэша, потому что вычисление хеша обычно обходится дороже, чем сравнение ... и вы будете вынуждены полагаться на необработанное сравнение пикселей для проверки равенства при совпадении хэшей, поскольку хэши только доказывают неравенство.

Я не предоставил демонстрацию того, что Equals и GetHashCode бесполезны в Bitmap.Тем не менее, я продемонстрировал, что они часто предлагают пользователям неожиданные, неожиданные затраты и не будут хорошим решением в обычных случаях использования.Добавление дополнительной функциональности к подобному типу стоит дорого, и я не уверен, что это принесет большую пользу.И это часто будет стоить много.Это то, что вы должны реализовать самостоятельно или использовать стороннюю библиотеку.

Answer 4

Семантика равенства в .net Framework довольно хорошо стандартизирована; казалось бы, это нарушило бы принцип наименьшего удивления, если бы ссылки на растровые изображения проверялись на равенство так, как вы ожидали.