0

My objects in a complex structure have a property Dictionary<Object, Object> Annotations, where I can store meta and custom data used during some processing phases. I can now create a static readonly object UniqueName = new object() and use that as the key in the dictionary. I use a static readonly object because I know for sure that it is unique. No one else can ever create the exact same object instance. If instead I had used a string as a key, someone else could accidentally use the same string as the key and this could cause problems.

However, I understood from several sources (including here) that the default GetHashCode implementation is based on the location of the object in memory. This may change when the object is moved by the garbage collector, and this would cause the hash it returns to change. When that happens, the dictionary will be unable to find the value associated with the key object.

How can I ensure that an object that has no fields never changes its hash code during its life time?

The naive solution is to create a Key object whose GetHashCode always returns 42. However, this would severely impact the performance of the dictionary and is therefore not a solution.

Community
  • 1
  • 1
Daniel A.A. Pelsmaeker
  • 47,471
  • 20
  • 111
  • 157
  • 1
    Uhmmm. just use the default `GetHashCode` implementation? – Steven Oct 04 '12 at 10:20
  • @Steven You clearly did not read the text. – Daniel A.A. Pelsmaeker Oct 04 '12 at 10:21
  • 1
    Doesn't mean he's not right though. GetHashCode over a non-mutable object ain't gonna change during the running of your executable. – spender Oct 04 '12 at 10:23
  • it's the implementation that might change and therefor produce a different hash when the code is run on different veersions of .NET within the life time of an AppDomain it will not change – Rune FS Oct 04 '12 at 10:26
  • @RuneFS Do you have any sources to back that statement up? All I read is that you *must* override `GetHashCode` as the default implementation is no good. If hash codes are guaranteed to not change during the life time of an object, then there is not much reason to bother with overriding it. – Daniel A.A. Pelsmaeker Oct 04 '12 at 10:30
  • The source you quote doesn't actually support your statement. – harold Oct 04 '12 at 10:30
  • yes I do :) the link you provide would be one of them `The index is unique to an instance of an object within an AppDomain for an instance of the executing engine` and there's pleanty of reasons to oveerload one would be when you ovreload the comparison operator/Equals if x==y then it's expected that they have the same hash code, which is not the case for the default implementation – Rune FS Oct 04 '12 at 10:47

2 Answers2

2

implementation may change the hash it returns

The default hash code implementation will never change the value of a single object. It will never change during the lifetime of that object and can therefore safely be used. I (quickly) read those answers you're pointing at, but they don't talk about hash codes that change during the lifetime of a single object.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • Do you have any sources to back this statement up? – Daniel A.A. Pelsmaeker Oct 04 '12 at 10:33
  • 1
    @Virtlink yes, your own source. "The index is unique to an instance of an object within an AppDomain for an instance of the executing engine. However, because this index can be reused *after the object is reclaimed during garbage collection*, it is possible to obtain the same hash code for two different objects." – harold Oct 04 '12 at 10:39
  • @harold: It talks about how the index is unique to an object instance, not about how it never changes. And apparently, according to the second sentence, it is not even unique. – Daniel A.A. Pelsmaeker Oct 04 '12 at 10:41
  • @Virtlink it would say that if I had quoted more, but it got a bit long. And no it is not unique, but it is unique *at any one time*, and that's good enough because it means the earlier one isn't in any dictionary/hashtable anymore anyway. – harold Oct 04 '12 at 10:43
  • 1
    And even if there are multiple objects with the same hashcode in a dictionary, that is not a problem, because hashcodes are not guaranteed to be unique any way. However, they are garanteed to never change on the same instance. – Steven Oct 04 '12 at 11:02
2

The default implementation of GetHashCode returns an index, rather than a memory address. This index is unique for the lifetime of the object, so even if your object is moved around in memory it will always return the same value when you call GetHashCode

However, once the object is garbage collected it valid for a new object you create afterwards to return the same value as a previous object did prior to garbage collection.

In your example the UniqueName variable will always return the same value when you call GetHashCode, and no instance of Object that you create will ever return the same hash code for the lifetime of your program.

Sean
  • 60,939
  • 11
  • 97
  • 136
  • There is no guarantee that multiple instances of `Object` created at different times will not return the same value, even if their lifetimes overlap. Hashcodes are chosen in such a way that hash collisions should not cause a performance drain on reasonably-designed hashed collections, but that in no way implies uniqueness. Today's computers are fast enough that a program could generate more than 4.3 billion objects in a single run; there's no way that many objects could all have unique `GetHashCode` values. – supercat Jan 21 '13 at 20:52