Hey Helge,
Thanks for your reply. I appreciate that as Hashcodes determined by a
GetHashcode method are only integer values there is a finite number of
results with collision a possibility. Part of the reason why I am using
hashcodes is that I need to calculate whether objects have changed when
exporting from another system. I store hashcodes in a database and then
compare the hashcode of the exported object with the value that has
previously been stored in the database.
Is there a better way of creating a hashcode of an object that will have
less collision than a GetHashCode integer?
I agree that for comparing two objects (rather than object vs hashcode -
above) implementing the IEqualityComparer<T> would be better. I'm also aware
that hashing is *not* equality (see my overriden Equals method below).
Perhaps my wording was not correct.
public override bool Equals(object obj)
{
// Check that the parameter has value
if (obj == null) return false;
// Check that types are the same
if (GetType() != obj.GetType()) return false;
// safe because of the GetType check
Customer customer = (Customer)obj;
// Check if hash codes match (being the same does not guarantee
equality
// however if the hashcode are different then definitely not
equal)
if (! GetHashCode().Equals(customer.GetHashCode())) return false;
return true;
}
"Helge Jensen" wrote:
Metaman wrote: Thanks for your reply Barry. It slipped my mind that GetHashCode method is on
the base object as well so that makes things a little easier. The reason that
I am writing this function is that I have a number of objects that contain
quite a lot of properties. I need a reliable way of comparing two objects of
the same type to see if they are the same. Even if only one of their
properties differs slightly I need to be made aware of it. After doing some
Then looking at the hash-codes won't be enough.
By convention:
x.Equals(y) => x.GetHashCode() == y.GetHashCode()
but
x.GetHashCode() == y.GetHashCode() =/> x.Equals(y)
If your hash-codes are intractible you may be able to argue equivalence
upto a certain acceptable error-margin, but really 2^32 is a very small
co-domain for an intractible hash.
If you wish to "fit into .NET" you should write an implementation of
IEqualityComparer<T> that uses reflections on the properties and
(recursively) applies hashing/comparison to the objects.
Note that computing the hash-value and comparing those to "optimize"
comparison will probably be a lot slower than just doing the comparison
inline, and unless you rely on intractability of the hash you will need
to do the comparison anyway.
I appreciate that this is not the most effiecient way of checking whether
objects are the same but not sure what a better way of generating a hashcode
could be.
hashing is *not* equality.
P.S. I actually override the Equals method first which checks the easy
things (makes sure that they are the same type etc..)
If x.Equals(y) then it should definatly be the case that x.GetHashCode()
== y .GetHashCode(), not the other way around.
--
Helge