By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,668 Members | 1,606 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,668 IT Pros & Developers. It's quick & easy.

value types and GetHashCode

P: n/a
I have defined a struct in my application that contains 3 integers
that maintain state information. I have a lot of these structs in
time-critical portions of my app, so they must be as fast as possible.
I also log previous values in arrays, so data size can't be ignored.

The data is such that I can implement value semantics by implementing
IComparable.CompareTo and overriding all the comparison operators as
well as Object.Equals(object o).

Since I have overriden the equality operators, the compiler keeps
suggesting I override Object.GetHashCode(). From reading the docs, I
realize GetHashCode() must return the same value for any given
instance and should be based on an immutable data member. However, my
value type is NOT immutable; I am constantly modifying values as state
changes and don't want the overhead of copying the struct every time I
need to change any of the 3 int fields.

Do I really need to be concerned about this? Can I accept the
default implementation of Object.GetHashCode() even though my struct
is not an object unless it is boxed? I really don't want to add a new
field just for HashCode support because that increases my data size by
33%!

I'm not planning on using this struct in a Hashtable or in collections
at this point, but that may happen in the future.

I would appreciate any insights into this problem!
Nov 15 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Fuzzy <tr******@earthlink.net> wrote:
I have defined a struct in my application that contains 3 integers
that maintain state information. I have a lot of these structs in
time-critical portions of my app, so they must be as fast as possible.
I also log previous values in arrays, so data size can't be ignored.

The data is such that I can implement value semantics by implementing
IComparable.CompareTo and overriding all the comparison operators as
well as Object.Equals(object o).

Since I have overriden the equality operators, the compiler keeps
suggesting I override Object.GetHashCode(). From reading the docs, I
realize GetHashCode() must return the same value for any given
instance and should be based on an immutable data member. However, my
value type is NOT immutable; I am constantly modifying values as state
changes and don't want the overhead of copying the struct every time I
need to change any of the 3 int fields.

Do I really need to be concerned about this? Can I accept the
default implementation of Object.GetHashCode() even though my struct
is not an object unless it is boxed? I really don't want to add a new
field just for HashCode support because that increases my data size by
33%!


Value types don't really *have* instances, in a way - it's not like
there can be two references to the same instance, there would just be
two completely independent values.

Basically, you can override GetHashCode just based on your values.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #2

P: n/a
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP************************@msnews.microsoft. com>...

Value types don't really *have* instances, in a way - it's not like
there can be two references to the same instance, there would just be
two completely independent values.

Basically, you can override GetHashCode just based on your values.


Yes, that is obvious, and I realized it soon after I posted! Anything
that goes into a HashTable is a copy *anyway*, so what difference does
it make!?!

Thanks for taking the time to respond.
Nov 15 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.