Re: Massive speed improvement in GObject type checking code

[Tim Janik <timj gtk org>]

On Mon, 18 Jun 2001, Alex Larsson wrote:

> On Sun, 17 Jun 2001, Tim Janik wrote:
> 
> > > I'm not sure. Considering that inline functions in C or statement
> > > expressions aren't portable, and I think GObject should probably
> > > perform portably, it's conceivable that the danger is worth it.
> > > I think it was worth it for the GTK_OBJECT() macro.
> >
> > i don't think there's much to worry about compilers that can't inline
> > nowadays. glib ensures that static inline at least works on such systems
> > by providing a non-static linkable version, if static inline isn't supported.
> > so worst-case scenario is that for inline-incapable compilers an extra
> > function call is performed.
> 
> I'd like to point out here that GCC produces better code for macros than
> inline functions. This will continue to be true in GCC 3.0, and in the
> future until the tree inliner is ported from the c++ compiler to the c
> compiler.

well, for gcc you can use the ({ TYPE var = (arg); retval; }) extension,
if that produces better code than using static inline instead, feel
free to provide a gcc-special cased patch, once we have the static inlines ;)

> 
> / Alex
> 

---
ciaoTJ