Non-readonly field referenced in GetHashcode

Can someone explain this inspection warning?  I did a search on it, and came
up empty...

Why is this a bad thing again?


2 comments

Eric Lippert explains all:
http://blogs.msdn.com/b/ericlippert/archive/2011/02/28/guidelines-and-rules-for-gethashcode.aspx

Guideline: The integer returned by GetHashCode should never change

Ideally, the hash code of a mutable object should be computed from only fields which cannot mutate, and therefore the hash value of an object is the same for its entire lifetime.

However, this is only an ideal-situation guideline; the actual rule is:

Rule: The integer returned by GetHashCode must never change while the object is contained in a data structure that depends on the hash code remaining stable

It is permissible, though dangerous, to make an object whose hash code value can mutate as the fields of the object mutate. If you have such an object and you put it in a hash table then the code which mutates the object and the code which maintains the hash table are required to have some agreed-upon protocol that ensures that the object is not mutated while it is in the hash table. What that protocol looks like is up to you.

If an object's hash code can mutate while it is in the hash table then clearly the Contains method stops working. You put the object in bucket #5, you mutate it, and when you ask the set whether it contains the mutated object, it looks in bucket #74 and doesn't find it.

Remember, objects can be put into hash tables in ways that you didn't expect. A lot of the LINQ sequence operators use hash tables internally. Don't go dangerously mutating objects while enumerating a LINQ query that returns them!

0

Thanks!  That makes sense.


"Richard Deeming"  wrote in message
news:18545554.22541314207796767.JavaMail.devnet@confluence.jetbrains.net...

Eric Lippert explains all:
http://blogs.msdn.com/b/ericlippert/archive/2011/02/28/guidelines-and-rules-for-gethashcode.aspx

Guideline: The integer
returned by GetHashCode should never change

Ideally, the hash code of a mutable object should be computed from only
fields which cannot mutate, and therefore the hash value of an object is the
same for its entire lifetime.

However, this is only an ideal-situation guideline; the actual rule is:

Rule: The integer returned by GetHashCode must never change while the
object is contained in a data structure that depends on the hash code
remaining stable

It is permissible, though dangerous, to make an object whose hash code value
can mutate as the fields of the object mutate. If you have such an object
and you put it in a hash table then the code which mutates the object and
the code which maintains the hash table are required to have some
agreed-upon protocol that ensures that the object is not mutated while it is
in the hash table. What that protocol looks like is up to you.

If an object's hash code can mutate while it is in the hash table then
clearly the Contains method stops working. You put the object in bucket #5,
you mutate it, and when you ask the set whether it contains the mutated
object, it looks in bucket #74 and doesn't find it.

Remember, objects can be put into hash tables in ways that you didn't
expect. A lot of the LINQ sequence operators use hash tables internally.
Don't go dangerously mutating objects while enumerating a LINQ query that
returns them!


---
Original message URL: http://devnet.jetbrains.net/message/5317544#5317544

0

Please sign in to leave a comment.