GNOME Bugzilla – Bug 592817
Inserting into HashMap creates copy of the key before insertion (conflict with g_direct_{hash,equal})
Last modified: 2009-09-28 17:50:11 UTC
Quoting http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543249: If I use HashMap.get() in the Vala program, it returns null. The attached Vala code can be used to reproduce the bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=map-get-always-null.vala;att=1;bug=543249
The problem apparently is, that vala compiles this to a hashmap that uses the pointer to the key as hash and comparing it as equality function. Now the hashmap internally strdups the key, resulting in a new pointer that is not known outside the hashmap. Asking for the old key will never give a result because new_key != old_key
Changing it to Gee.HashMap<string,string> map = new Gee.HashMap<string,string>(GLib.str_hash, GLib.str_equal, GLib.str_equal); makes it work. Not sure if there's anything to fix here
Maybe the HashMap should assume that the keys passed are transfered ownership to the HashMap. This problem is not only specific to strings but to everything (except scalar types) because in any case the copy function is called for the keys before storing them. And a copy function will change the output of a direct hash (unless the copy really is a g_object_ref() ).
Current implementation special cases the strings.
commit 23721f320c6cd3a13e54731ddcfe28442cfa2b63 Author: Didier 'Ptitjes <ptitjes@free.fr> Date: Mon Sep 28 19:44:32 2009 +0200 Fix the documentation of all implementations' constructor Fixes bug 592817. Now the constructors of all implementations and the Functions function factory are well documented. Sane defaults are provided for (non-boxed) primitive, string and object types (with a special care for those inheriting Gee.Comparable) as explained in the documentation. Closing the bug. Could you, Sebastian, please close the one of Debian ? Thank you.