On 26 Mar 2011, at 01:23, Peter Lübke wrote: > Thank you, Mike, for showing me I was taken away by my own fantasy about > hash... > > Am 26.03.2011 um 01:22 schrieb Mike Abdullah: > >> It sounds like you're rather misunderstanding what -hash does. Cocoa classes >> are free to cover the full range of possible hash values. > > In the meantime, I read some related posts on the list and had to recognize > this, too...Sorry, this was the first time I was looking at hash values at > all. > >> You can't have a value that "interferes" with the framework; at worse you >> could reduce performance IF putting custom objects in the same container as >> framework-provided classes. Even then you'd be hard-pressed to do this >> regularly. > > To be more detailed: my custom class and its subclasses are wrapper classes > containing file informations. They are based on FSRef rather than using paths > - I do a lot of lengthy iterations so paths are much too fragile. I also > heavily use NSSet to store instances, and I wanted -isEqual: to be as fast as > possible. So I thought I could just return a unique hash value for each > custom class and return (FSCompareFSRefs (&ownRef, &otherRef) == noErr) for > -isEqual:, thus avoiding the need to *first* compare the objects' classes.
This is pretty much what NSSet will be doing for you. It uses -hash to narrow down possible matches, before calling -isEqual: only on those that share a hash. You should find this plenty enough fast enough if your hash values actually are unique. If not, about the only optimization from there is a NSHashTable or CFSet setup to test equality on -hash._______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
