[vtk-developers] hast table in VTK

[Moreland, Kenneth]

There must be some miscommunication here, because the class I'm
describing works exactly the same as the Hashtable class that has been
distributed with Java since the language's creation.  The features I
describe are not only possible, but often useful.

> > The pointer value is not always a valid value to hash on.  
> Sometimes
> > objects that have different pointers can be considered equal.
> 
> In that case the object is not stored in the map and really is a key 
> to something else, even if it is an object considered equal.

Here is a toy example.  Let's say I want to keep a collection (that is,
a set, not a map) of faces in a mesh with some special property.  As I
do some computation on the mesh, I want to quickly check to see if the
face I'm working on is part of this set.  I should be able to do this by
storing a bunch of objects in the hashtable (perhaps vtkPolygon objects)
that identify the faces by their point ids.  As I do my computation, I
could easily make two objects that describe the same face.  Therefore, I
want two of these objects to be "equal" if they describe the same face
even if they are in different locations in memory.

Another example: you have a collection of strings that you store in the
hashtable.  You want to see if an incoming string is contained by the
hashtable.  You almost always want to check the contents of the string,
not the pointer to the string.

> If the pointer value is not the key then I don't think a single hash 
> key virtual function will work either.  The key to use for the object 
> could change depending on the application of the hash table.

Well, yes.  Like Java objects, all VTK objects that override the default
HashCode and Equals methods would have to follow two critera for the
hash code to make sure the hashtable stays valid.  (BTW, these are taken
from the Java API documentation.)

1. Whenever it is invoked on the same object more than once during
program execution, the HashCode method must consistently return the same
integer, provided no information used in Equals comparisons on the
object is modified.  This integer need not remain consistent from one
execution of an application to another execution of the same
application.

2. If two objects are equal according to the Equals method, then calling
the HashCode method on each of the two objects must produce the same
integer result.

Obviously, the performance of the hash table depends heavily on a good
hash code.  Also, any change to the object that would change the result
of the Equals method could invalidate any hashtable it is stored in.
Such is the pitfall of many collections including STL sets and maps.

> Instead I suggest that the
> objects be stored paired with another key on which the hash function 
> is defined.

If you are looking for an object containing some particular data, I have
no idea how that would help.

-Ken