Re: [boost] Re: [review] hash functions
In-Reply-To: <019d01c52985$a04f54f0$6801a8c0@pdimov> pdimov@mmltd.net (Peter Dimov) wrote (abridged):
You also need equal_ptr<MyType>.
Indeed.
Also, it is easy to break the above unordered_set my modifying some of the MyTypes.
Yes, that's something to be aware of. I use the approach on types which are immutable, so it doesn't arise.
size_t Derived::hash_value() const { size_t seed = my_unique_value;
hash_combine( seed, Base::hash_value() ); hash_combine( seed, m_value );
return seed; }
That leaves the problem of assigning a different my_unique_value to each subclass, bearing in mind that different subclasses may be written by different people, teams or organisations. Without some kind of system people may just copy and paste code from one class to another and not change the value. -- Dave Harris, Nottingham, UK
Dave Harris wrote:
In-Reply-To: <019d01c52985$a04f54f0$6801a8c0@pdimov> pdimov@mmltd.net (Peter Dimov) wrote (abridged):
size_t Derived::hash_value() const { size_t seed = my_unique_value;
hash_combine( seed, Base::hash_value() ); hash_combine( seed, m_value );
return seed; }
That leaves the problem of assigning a different my_unique_value to each subclass, bearing in mind that different subclasses may be written by different people, teams or organisations. Without some kind of system people may just copy and paste code from one class to another and not change the value.
Perhaps, but this is the only correct way to write Derived::hash_value. Consider the properly designed hierarchy of an abstract Base and two Derived classes, both having an int member. Without using typeid().name() or an unique seed, there will be collisions. Again, we can hide these errors from the users by making some cases produce reasonable hash values when the hash function is incorrectly written. I view this as a disservice.
participants (2)
-
brangdon＠cix.compulink.co.uk -
Peter Dimov