Complex Objects as Hash Keys

If I take a complex reference object and make it the key of a hash table,
can I be sure that the hash of that object will always remain the same
throughout the life of that object?

Every reference object has a reference pointer that is, I would guess, some
integer. If I'm right, that integer is what gets hashed when you make such
an object a key in a hash table. If I'm right, is that integer guaranteed to
be immutable throughout the life of the object, or does garbage collection
cause a change in this integer, such that the same object now has a new
reference number?

My concern is that if this reference integer does not remain constant,
entries in the Hashtable could become invalid.

Randy Neall

Mattias
Fri Jun 11 14:01:51 CDT 2004


>can I be sure that the hash of that object will always remain the same
>throughout the life of that object?

That depends on the implementation of GetHashCode(). For the default
implementation it's true.


>Every reference object has a reference pointer that is, I would guess, some
>integer.

I don't quite understand what you mean here.


>If I'm right, that integer is what gets hashed when you make such
>an object a key in a hash table.

Any data can be used to derive the hash. Again, it depends on the
GetHashCode() implementation.


>or does garbage collection cause a change in this integer

I don't think garbage collection could ever change the hash. But
making mutating changes to the object could.



Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Randolph
Fri Jun 11 14:34:13 CDT 2004

Thanks Mattias,

What I meant by "some integer" is the object's handle, presumably some
number.

So when I set the key of a hash table to a reference object, the hash value
that is used comes from that object's own GetHashKey method? And that hash
reflects both the "handle" of the object and the content of the object? Does
the "handle" always remain the same? Every object, I assume, has some handle
that should be independent of its particular values, fields, and properties.
What is it that gets hashed when you make a reference object the key of a
hash entry--the handle, the object's content (which can change), or both?
Under what conditions, if any, would the default hash of an object change
over its lifetime? What did you mean by "mutating changes?" Changes to
properties and fields?

Randy

Jerry
Fri Jun 11 15:37:46 CDT 2004

Inline...

"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
news:e8W8ca%23TEHA.2028@TK2MSFTNGP11.phx.gbl...
>
>>can I be sure that the hash of that object will always remain the same
>>throughout the life of that object?
>
> That depends on the implementation of GetHashCode(). For the default
> implementation it's true.

No it isn't -
http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemObjectClassGetHashCodeTopic.asp.
Therefore you can't use the deault GetHashCode implementation for hashing.

>>Every reference object has a reference pointer that is, I would guess,
>>some
>>integer.
>
> I don't quite understand what you mean here.

Not an integer but a pointer.

>>If I'm right, that integer is what gets hashed when you make such
>>an object a key in a hash table.
>
> Any data can be used to derive the hash. Again, it depends on the
> GetHashCode() implementation.

Randolph is right and you can't use that for hashing. You have to implement
your own GetHashCode that will return the same value for a single object, no
matter what happens to that object.

>>or does garbage collection cause a change in this integer
>
> I don't think garbage collection could ever change the hash. But
> making mutating changes to the object could.

Yes it does, for the default Object.GetHashCode implementation it does. Once
again, DO NOT USE IT in hash tables.

> Mattias
>
> --
> Mattias Sjögren [MVP] mattias @ mvps.org
> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> Please reply only to the newsgroup.

Randolph
Sun Jun 13 11:46:16 CDT 2004

Hey Jerry,

Can't thank you enough for jumping in here. I've taken your message to
heart. We could have had some really vile bugs on our hands.

Thanks,

Randy Neall


"Jerry Pisk" <jerryiii@hotmail.com> wrote in message
news:uKKyvP$TEHA.3664@TK2MSFTNGP12.phx.gbl...
> Inline...
>
> "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
> news:e8W8ca%23TEHA.2028@TK2MSFTNGP11.phx.gbl...
> >
> >>can I be sure that the hash of that object will always remain the same
> >>throughout the life of that object?
> >
> > That depends on the implementation of GetHashCode(). For the default
> > implementation it's true.
>
> No it isn't -
>
http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemObjectClassGet
HashCodeTopic.asp.
> Therefore you can't use the deault GetHashCode implementation for hashing.
>
> >>Every reference object has a reference pointer that is, I would guess,
> >>some
> >>integer.
> >
> > I don't quite understand what you mean here.
>
> Not an integer but a pointer.
>
> >>If I'm right, that integer is what gets hashed when you make such
> >>an object a key in a hash table.
> >
> > Any data can be used to derive the hash. Again, it depends on the
> > GetHashCode() implementation.
>
> Randolph is right and you can't use that for hashing. You have to
implement
> your own GetHashCode that will return the same value for a single object,
no
> matter what happens to that object.
>
> >>or does garbage collection cause a change in this integer
> >
> > I don't think garbage collection could ever change the hash. But
> > making mutating changes to the object could.
>
> Yes it does, for the default Object.GetHashCode implementation it does.
Once
> again, DO NOT USE IT in hash tables.
>
> > Mattias
> >
> > --
> > Mattias Sjögren [MVP] mattias @ mvps.org
> > http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> > Please reply only to the newsgroup.
>
>

Jerry
Sun Jun 13 20:56:27 CDT 2004

No problem, I can't imagine the pain of trying to hunt down bugs caused by
the hash code changing...

Jerry

"Randolph Neall" <randolphneall@veracitycomputing.com> wrote in message
news:OPVWUXWUEHA.1284@TK2MSFTNGP10.phx.gbl...
> Hey Jerry,
>
> Can't thank you enough for jumping in here. I've taken your message to
> heart. We could have had some really vile bugs on our hands.
>
> Thanks,
>
> Randy Neall
>
>
> "Jerry Pisk" <jerryiii@hotmail.com> wrote in message
> news:uKKyvP$TEHA.3664@TK2MSFTNGP12.phx.gbl...
>> Inline...
>>
>> "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
>> news:e8W8ca%23TEHA.2028@TK2MSFTNGP11.phx.gbl...
>> >
>> >>can I be sure that the hash of that object will always remain the same
>> >>throughout the life of that object?
>> >
>> > That depends on the implementation of GetHashCode(). For the default
>> > implementation it's true.
>>
>> No it isn't -
>>
> http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemObjectClassGet
> HashCodeTopic.asp.
>> Therefore you can't use the deault GetHashCode implementation for
>> hashing.
>>
>> >>Every reference object has a reference pointer that is, I would guess,
>> >>some
>> >>integer.
>> >
>> > I don't quite understand what you mean here.
>>
>> Not an integer but a pointer.
>>
>> >>If I'm right, that integer is what gets hashed when you make such
>> >>an object a key in a hash table.
>> >
>> > Any data can be used to derive the hash. Again, it depends on the
>> > GetHashCode() implementation.
>>
>> Randolph is right and you can't use that for hashing. You have to
> implement
>> your own GetHashCode that will return the same value for a single object,
> no
>> matter what happens to that object.
>>
>> >>or does garbage collection cause a change in this integer
>> >
>> > I don't think garbage collection could ever change the hash. But
>> > making mutating changes to the object could.
>>
>> Yes it does, for the default Object.GetHashCode implementation it does.
> Once
>> again, DO NOT USE IT in hash tables.
>>
>> > Mattias
>> >
>> > --
>> > Mattias Sjögren [MVP] mattias @ mvps.org
>> > http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
>> > Please reply only to the newsgroup.
>>
>>
>
>

Mattias
Mon Jun 14 05:36:31 CDT 2004

Jerry,

>>>can I be sure that the hash of that object will always remain the same
>>>throughout the life of that object?
>>
>> That depends on the implementation of GetHashCode(). For the default
>> implementation it's true.
>
>No it isn't -
>http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemObjectClassGetHashCodeTopic.asp.
>Therefore you can't use the deault GetHashCode implementation for hashing.

If I recall correctly, the v1.x framework's Object.GetHashCode
implementation returns the syncblock index, which should be
consistent.

But that's of course just an implementation detail, and you're right
that you shouldn't use it since there are no guarantees.



Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Jerry
Mon Jun 14 06:56:24 CDT 2004

You might be right, I just went through the docs saying that the default
implementation isn't guaranteed to do that. That of course doesn't mean it
isn't, just that we shouldn't rely on it.

Jerry

"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
news:OSW36tfUEHA.1560@TK2MSFTNGP09.phx.gbl...
> Jerry,
>
>>>>can I be sure that the hash of that object will always remain the same
>>>>throughout the life of that object?
>>>
>>> That depends on the implementation of GetHashCode(). For the default
>>> implementation it's true.
>>
>>No it isn't -
>>http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemObjectClassGetHashCodeTopic.asp.
>>Therefore you can't use the deault GetHashCode implementation for hashing.
>
> If I recall correctly, the v1.x framework's Object.GetHashCode
> implementation returns the syncblock index, which should be
> consistent.
>
> But that's of course just an implementation detail, and you're right
> that you shouldn't use it since there are no guarantees.
>
>
>
> Mattias
>
> --
> Mattias Sjögren [MVP] mattias @ mvps.org
> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> Please reply only to the newsgroup.