Re: on replacing GTK_WIDGET_* with gtk_widget_get_* INSIDE gtk+

[Christian Dywan <christian lanedo com>]

Am Wed, 17 Mar 2010 17:10:02 +0000
schrieb Emmanuele Bassi <ebassi gmail com>:

> On Wed, 2010-03-17 at 17:49 +0100, Christian Dywan wrote:
> 
> > > recently there's been a flood of changes in gtk+ where *internal*
> > > uses of GTK_WIDGET_* macros accessing the widget flags were
> > > replaced by the new public accessors. Why is that? I thought the
> > > GSEAL work was intended to only seal *outside* access to the
> > > flags, while library-internal code could continue to use the
> > > shortcuts macros. These changes mean that every time I rebase my
> > > gtk tree, I have some patches that fail to apply because of this;
> > > I guess I'm not the only one that this is happening to!
> 
> > the plan is indeed to remove the old macros entirely, not just hide
> > them. Fortunately these replacements are almost done, so you should
> > have survived most rebasing trouble.
> 
> the obvious downside is that now every single accessor will have to go
> through the type check in the argument validation - and a function
> call. not really good, performance wise. I'll just set aside any
> comment on why we should have sealed the flags member, since it would
> be pointless
> - the change already happened.
> 
> this might be the kick in the arse needed to get type checking down
> to a minimal cost, but still it might not be a good thing to dump on
> unsuspecting audience without a warning at least in the release notes.
> 
> it would be good to get some numbers, and possibly a fallback for
> internal usage. or, if the numbers are that bad, reconsider sealing
> the flags.
> 
> ciao,
>  Emmanuele.

Hey Emanuelle,

it is not quite the same as externally calling a function, but you are
right in terms of additional type checking. I don't know if the
overhead is noticible in practise, but I agree it is worth looking
into, as it came up before and shouldn't be ignored without argument.

I might see if I find some time to look into it. It should be
straightforward to add a private header that re-defines these functions
as macros.

ciao,
    Christian