On Aug 26, 2004, at 10:56 PM, Ryan McDougall wrote:
Perhaps its my ignorance of GValue, why is memory allocation GValue's problem, thus necessitating an unset function. Shouldn't I dealloc my own pointers?
GValues are used in code that runs a *lot* (marshaling code for signals, property mechanism, etc), and need to be fast. allocation on the stack is far faster than allocation on the heap, and you don't have to worry about it failing (it happens automatically, even). thus, the GValue API, like the GtkTreeIter API, is designed to allow you to use values on the stack. if it's on the stack, you're not going to be calling free() on it, so you need some way to release any resources it may contain; hence g_value_unset(), which brackets nicely with g_value_set_*().
For some internal code, I prefer to pass a heap allocated GValue pointer
to some unnecessary copies of stack alloc'd GValues[...]
"unnecessary copies of stack alloc'd GValues"? could you elaborate here? from what i can see, you always pass GValues by reference, not by value. why would they be copied?
, so I use it outside
of the tutorial (which can be changed). Basically I don't see any reason
*not* to add it once the g_new0 bug is fixed.
the only place where i see heap-allocated GValues being necessary is in something like a collection container, where you're going to hang on to them for longer than the stack frame will be alive. in that case, g_new0() by itself is sufficient, but g_value_new() would be nice for readability.
-- elysse (pregnant): are your hands cold? me: uh, i suppose so. elysse: will you put them on me?
_______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
