Re: g_value_new Macro?

[muppet <scott asofyet org>]

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?