On Tue, Jan 19, 2010 at 2:33 PM, Jeremy Pereira <a...@jeremyp.net> wrote: > > On 19 Jan 2010, at 16:53, Shawn Rutledge wrote: > >> I'm accustomed to >> things like Qt and Java where hashtables can contain anything for both >> key and value. > > This is not true (at least for Java and probably for QT for the same reason). > From the API docs for the Map abstract class: > > "Note: great care must be exercised if mutable objects are used as map keys. > The behavior of a map is not specified if the value of an object is changed > in a manner that affects equals comparisons while the object is a key in the > map. "
Well yeah, that's one of the reasons java.lang.String is immutable. But it helps that java.lang.Object has both hashCode and equals, so any object can be put into a collection that depends on those... you just have the option of improving the implementation of those for better hash distribution, comparing two objects by content rather than reference location, etc. I just wanted a hashtable that uses keys by pointer rather than expecting to copy them. Nice to know that copying protocol doesn't mean you have to actually copy it though. As for C++, you can use template containers to store either pointers or copies of objects, whichever you like. _______________________________________________ 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
