From MSDN documentation, it seems as both GetHashCode() and Equals() haven’t been overriden in Bitmap. Neither have them been overriden in Image. So both classes are using the Object’s version of them just compares references. I wasn’t too convinced so I decided to fire up Reflector to check it out. It seems MSDN is correct in that matter.
So, is there any special reason why MS guys wouldn’t implement “comparison logic”, at least for the Bitmap class? I find it is kinda acceptable for Image, as it is an abstract class, but not so much for the Bitmap class. I can see in a lot of situations calculating the hash code can be an expensive operation, but it’d be alright if it used some kind of caching.
When wanting to compare 2 bitmaps, will I have to resort to having to run all over the picture comparing each one of its pixels?
Thanks
Let’s flip that question around; is there any special reason why they would implement such a thing?
For one thing, it would be very, very expensive to compute the hash, making it all but useless for hash tables and the like. Just try to imagine doing this on a whole slew of 1920×1200 bitmaps; doing it even one time for each bitmap would slow the program to a crawl. I would expect that 9 times out of 10, when somebody has to compare two bitmaps, they want reference equality, not pixel-by-pixel value equality.
And what you refer to in your question isn’t lazy evaluation, it’s caching. Caching is a non-trivial feature to implement, and every feature starts at minus 100 points.
With all that in mind, my answer to this would be that the methods aren’t overridden because the overridden versions wouldn’t be particularly useful to many people, relative to the cost of implementing and maintaining such a feature. If you really want pixel-by-pixel comparisons (or checksums, or similar things), then you can always implement them yourself in 10 lines or so.