Re: Signal memory leak.

[Tim Janik <timj gtk org>]

On Sun, 9 Jan 2000, David Benson wrote:

> > No, it actually must be a GtkObject because it will be cast to one
> > on the call.
> > 
> >                 /* don't cast with GTK_OBJECT () */
> >                 (* signal->marshaller) ((GtkObject*) handlers->func_data,
> >                                         handlers->func,
> >                                         object,
> >                                         params);
> 
> In C (and in C++ w/o MI), you can just pass and cast
> pointers w/o their values being changed, even if the cast
> is fully invalid.  For example:
> 
> static void print_string(const char* string)
> {
> 	g_message("%s", string);
> }
> 
> ...
> 
> gtk_signal_connect_object(GTK_OBJECT(button), "clicked",
>                           GTK_SIGNAL_FUNC(print_string),
> 			  (GtkObject*) "hello, joe");
> 
> 
> This works, and has the advantage that "print_string" isn't specialized
> for a particular signal type.
> 
> > I guess I just don't understand why there was such a distinction.  
> > gtk_connect_object seems dangerous and outdated.  While alive
> > would seem that the more appropriate behavior. 
> 
> Both behaviors are desirable and fashionable :),
> IMHO the function's name is the problem.
> It should be `gtk_object_connect_swapped' or `gtk_object_connect_other'
> and take a gpointer.

you're completely right, in fact i alread have a rename
of that function on my TODO list for 1.4. unfortunately
we will have to stay backwards compatible, so it'll
probably amount to

guint gtk_signal_connect_data (GtkObject    *object,
                               const gchar  *signal,
                               GtkSignalFunc func,
                               gpointer      data);
/* in gtkcompat.h: */
#define gtk_signal_connect_object gtk_signal_connect_data                               

---
ciaoTJ