Re: glib question - what to free from hashes

[Vlad GALU <dudu diaspar rdsnet ro>]

On Mon, 26 Apr 2004, Gus Koppel wrote:

> Vlad GALU wrote:
>
> > Is it OK if I free the elem/key pairs from a hash table inside
> > the GHRfunc that I pass to g_hash_table_foreach_remove() ?
>
> If you intend to free the hash table entry with a call to
> g_hash_table_remove () inside the GHRFunc: NO!
>
> The GHRFunc is merely meant to be a test function for the elements of
> your hash table. It has just to DECIDE whether particular elements
> should be freed or not. Actual freeing of entries is performed by
> g_hash_table_foreach_remove () itself, if your GHRFunc indicates that
> this is okay for the particular entry.
>
> However,
> if you intend to free the DATA pointed to by "key" and "value" with
> g_free (), g_object_unref () or similar: YES!
        This is my case.

> Typical key/value pairs in a hash table consist of three items, each
> consuming its own chunk of memory:
> 1. the data pointed to by the "key" pointer
> 2. the data pointed to by the "value" pointer
> 3. the hash entry containing the "key" and "value" pointers
>
> Only 3. is freed by g_hash_table_foreach_remove () if GHRFunc permits
> it and no further precautions have been taken.
>
> If you were dynamically allocating the key and value data you were
> passing to g_hash_table_insert () it is okay to free it inside the
> GHRFunc. Although doing this is slightly less elegant than using
> GDestroyNotify functions for that, it will certainly save one or two
> function calls at runtime and thus be (very) slightly faster. However,
> you should not free key/value data inside your GHRFunc if it returns
> FALSE to g_hash_table_foreach_remove ()!
>
> And you may only free data you were dynamically allocating on your own
> before. If you fill a hash table with static data like constants then
> you must not free that! GHashTable does NOT create own, dynamic copies
> of the "key" and "value" data. Just POINTERS to them are copied and
> stored in the hash entry.

        Thanks a lot. Luckily, I got it right the first time, but I
thought to ask, because the glib docs aren't very clear about the memory
manangement issues when using its own data structures.
        However, I turned to glib2 and I used g_hash_table_new_full, and I
passed g_free as the key/element destructors. They were dinamically
allocated. Also, the GHRFunc returns TRUE if an element/key pair has to be
removed.
        The reason I asked this is because I also read about GTrees. And
the docs stated that I shouldn't remove an element while iterating
through the tree.

        Again, thank you for your time and patience.

> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

----
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.