Re: g_value_new Macro?

[James Henstridge <james jamesh id au>]

On 27/08/04 10:56, Ryan McDougall wrote:

> I spotted where the docs say it must be zero init'd, but I can't see in
> the source *why* thats needed. I guess so you don't call init on a value
> that has already been init'd without calling reset first.
>  
Well, the code in g_value_init() is checking whether the type field of 
the GValue is zeroed out.  It is right there in the code.

> 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?
>  
A GValue can be used to hold an arbitrary value, including things like 
strings and GObjects.  In the case of a string, the GValue holds an 
allocated string so not calling g_value_unset() will lead to the string 
being leaked.  In the case of a GObject, you will get a reference leak.  
Tommi mentioned this in his reply to you.

If the GValue is allocated on the stack, you only need to 
g_value_unset() it.  If you've allocated it on the heap, you will need 
to free the GValue itself.

> For some internal code, I prefer to pass a heap allocated GValue pointer
> to some unnecessary copies of stack alloc'd GValues, 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.
>  
When passing a GValue into a function you call, you'd usually pass it as 
"&value".  Note that this won't work if you want the value to last 
longer than the scope you defined it in.  In practice, this isn't a 
problem for the existing use cases (also, GValue isn't really that good 
a choice for long term storage).

[also note that doing a straight copy of a GValue is an error in most 
cases.  If you unset one copy, it will invalidate the other].

James.

--
Email: james jamesh id au
WWW:   http://www.jamesh.id.au/