Re: unordered_set
On Apr 7, 1:49 pm, Pete Becker <p...@versatilecoding.com> wrote:
On 2008-04-07 05:44:54 -0400, James Kanze <james.ka...@gmail.com> said:
On Apr 6, 11:57 pm, Pete Becker <p...@versatilecoding.com> wrote:
On 2008-04-06 17:43:20 -0400, Razii <DONTwhatever...@hotmail.com> said:=
On Sat, 05 Apr 2008 22:10:38 GMT, Erik Wikstr=F6m
<Erik-wikst...@telia.com> wrote:
You will have to supply a hash-function/functor yourself,
How come C++ library won't add something like this...
System.identityHashCode(theObject);
which returns internal address of the object by converting it into
an integer.
The user would have no need to specify a hashing function.
Because it's not a good hash function.
It could be a good hash function, if that's what you want.
First, the function doesn't return the internal address,
converted to an integer, but rather a hash code (undefined how)
based on the identity of the object. Since the garbage
collector can move objects, using the address of the object as a
hash code would cause more than a few problems.
Second, if I understand correctly, the next version of the C++
standard will provide the equivalent. I think, in fact, that it
was you that told it to me: an implementation is required to
specialize std::hash for pointer types. And since C++ doesn't
allow objects to change addresses, generating a hash code from
the object's address is a perfectly valid (and in fact probably
the best) way to generate a hash code based on identity.
"[G]enerating a hash code from the object's address" is not
the same as "return[ing the] address of the object".
Isn't that more or less what I said in the first paragraph of my
response?
The Java function cited above basically generates a hash code
somehow from the identity of the object. Since C++ doesn't
allow moving objects around in memory, the identity is basically
the object's address, and generating a hash code from the
object's address in C++ does more or less what
System.identityHashCode( object ) does in Java.
And hashing on pointer types when someone is putting pointers
into a container is not the same as hashing on object
addresses when someone hasn't written their own hash function.
Now that seems obvious. But the only use of
System.identityHashCode() in Java is to if you've written a
class which uses == (and not Object.equals()) for equality on
some of its subobjects.
As I said (somewhere, I think), one frequent error in Java is
overriding Object.equals(), but not Object.hashCode(). To be
fair, the Java documentation is very, very clear about the need
to override Object.hashCode() whenever you override
Object.equals(). A more robust implementation of
Object.hashCode() in the base class would have been something
along the lines of:
if ( equals is overridden ) {
return 0 ;
} else {
return System.identityHashCode( this ) ;
}
But robustness has never been a particular characteristic of
Java.
(BTW: maybe I am misinterpreting your original statements. With
regards to hash codes, I tend to consider good/bad as a
different distinction than correct/incorrect, with good/bad only
applying to correct hash codes. Thus, "return 0" is a correct
hash code, but it certainly cannot be considered a good hash
code. If by "not good", you meant "incorrect given the usual
equivalence function used", and not "correct, but with a bad
distribution", then I agree.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34