Re: g_value_new Macro?

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].


Email: james jamesh id au

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]