Re: user_data argument to a signal's class_closure which is a class function pointer member

[Tim Janik <timj gtk org>]

On 24 Jul 2003, Mathieu Lacage wrote:

> hi,
>
> While trying some GSignal code, I started using g_signal_new which
> creates a signal whose default handler is a function pointer, member of
> a structure.
>
> While doing this, I actually tried reading the user_data argument of
> this default handler even though none is explicitely provided in the API
> and was surprised to see something not zero come out of it.

there's no particular use for the user_data argument in this case, which
is why there's no special support for it in the signal code either.

but even if you had a die-hard situation where for some oddball reason
you'd need to get data to your class handler that you couldn't store anywhere
else (for instance in the class, but that's prolly too obvious... ;) you can
still use g_signal_newv() or g_signal_new_valist() with a closure which allowes
you to store as much data as you like.

> Some source code reading in gsignal.c shows the function named
> g_signal_type_cclosure_new which calls  closure = g_closure_new_simple
> (sizeof (GClosure), (gpointer) itype);

that functions prototype is:

GClosure* g_signal_type_cclosure_new            (GType          itype,
                                                 guint          struct_offset);

> Here, the itype argument to the g_closure_new_simple function is indeed
> an arbitrary value for the user_data argument of my signal's default
> handler.

the above prototype should give you a hint, that the class type and
the function pointer offset are essential to call a specific virtual
function of a specific class. naturally, those two data items will
have to be stored somewhere, and the code snippet you posted above
shows how the itype is being stored in the resulting closure.
(for those curious, the struct_offset is stored together with
a seperate marshaller that needs to be installed for class function
closures).

> So, the question is: is this special value part of the
> officially exported API ?

no it is not. the "official API" doesn't provide you with a user_data
argument to class functions if you use the *convenience* interface
g_signal_new(). do you have any good reasons to change that and can
present reasonable use cases for user_data with class functions?

> If not, would it be possible to set it to zero
> (or something like 0xdeadbeef) instead ?

yes, pretty easily. at the cost of enlarging class closures by
sizeof(GType), since i need to store the type somewhere else, if
user_data is going to be 0xdeadbeef.
i'm afraid, people will be right though, if they *then*
claim user_data to contain some "arbitrary" value ;)

> regards,
> Mathieu
> --
> Mathieu Lacage <mathieu gnu org>
>

---
ciaoTJ