Hi, Thank you Emmanuele, this makes things clearer. I've also read the glib-genmarshal page (https://developer.gnome.org/gobject/stable/glib-genmarshal.html) and I think I've understood this a bit more.
Then a VOID__VOID callback has the form: void func (gpointer data1, gpointer data2) I understand that data2 == user_data (the same user_data passed in cclosure_new). But what is data1? I know that when connecting signals, the first argument of the callback is the object that emitted the signal. This is my question now: what is the parameter that is passed in closure_invoke, and that is different from user_data? Thank you very much. Regards, Juan. On Apr 7, 2013, at 12:10 PM, Emmanuele Bassi wrote: > hi; > > On Sunday, April 7, 2013, Juan Rafael García Blanco wrote: > > Hello everybody, > > I've a few questions about how closures should be used. I'm writing a GLib > wrapper for OpenCL, and I feel the need to use callbacks. I'll try to explain > what I don't understand about closures. > > g_cclosure_new takes a pointer to user data as argument. This is passed to > the callback in its last argument. But then, when I call g_closure_invoke() I > need to pass a GValue array containing the arguments to the callback, and I > guess user_data is included here. I see this as a redundant action, so my > guess is I've got something wrong. I hope you can clarify this a little bit > for me. I'll appreciate it. > > you don't pass the user data when calling invoke(). the params[] array > contains only the arguments you specified in the marshaller. the user data > pointer that is then passed to the callback function is the one you used when > creating the GClosure. > > a side note: I would not use GClosure, especially if you're concerned about > performance. the GValue boxing and unboxing can become a performance > liability in critical paths. you should use function pointers directly, and > if you need generic arguments, you can resort to varargs. if push come to > shove, using libffi directly is another option at your disposal. > > ciao, > Emmanuele. > > > -- > W: http://www.emmanuelebassi.name > B: http://blogs.gnome.org/ebassi/ _______________________________________________ gnome-devel-list mailing list gnome-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-devel-list
