Re: GtkLabel patch

[Tim Janik <timj gtk org>]

On 28 Feb 2001, Havoc Pennington wrote:

> 
> Tim Janik <timj gtk org> writes: 
> > > @@ -119,24 +128,80 @@ gtk_label_get_type (void)
> > >  static void
> > >  gtk_label_class_init (GtkLabelClass *class)
> > >  {
> > > -  GObjectClass *gobject_class = G_OBJECT_CLASS (class);
> > > +  GObjectClass *gobject_class;
> > >    GtkObjectClass *object_class;
> > >    GtkWidgetClass *widget_class;
> > > 
> > > +  gobject_class = (GObjectClass*) class;
> > >    object_class = (GtkObjectClass*) class;
> > >    widget_class = (GtkWidgetClass*) class;
> > 
> > he, there was a reason that i put a G_OBJECT_CLASS() cast there originally.
> > actually, all class assignments should use the provided casting macros instead
> > of direct c casts, it's the same as for widget casts, i.e. they do additional
> > checking for debugging code.
> > 
> 
> That is just pointless slowness, there's no way on earth that
> typecheck will ever fail.

you bet.
first, worrying about slowness in debugging enabled code
is not a valid argument, by that reasoning we'd have to take
a huge portion of our checks out which defeats the purpose
_debugging_ checks (in case you wonder, take a look at
g_signal_emitv() how it checks all passed in arguments when
debugging is enabled).
second, i personally have run into it, and i've seen buggy
user code that would have triggered warnings from the above
checks, if they were just consistenly used. a common way to
run into them is creation of new widgets or changing the
ancestor of a widget. suddenly you might poke around in
a parent class that isn't actually your parent anymore.
using the class cast macros will catch that, not using them
might cause you a couple of hours debugging since most often
you just poked invalid values into some foreign struct
or screwed the memory allocation system.

> 
> Havoc
> 

---
ciaoTJ