[gst-devel] Re: Massive speed improvement in GObject type checking code

[Tim J. <ti...@gt...>]

On 19 Jun 2001, Owen Taylor wrote:

> 
> Tim Janik <ti...@gt...> writes:
> 
> > 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 ;)
> 
> 'static inline' is, of course, very much a GCC extension.

huh? that'd be new to me, "extern inline" is, but "static inline" should
be handled by any compiler that's capable of handling inline functions.

> 
>                                         Owen
> 

---
ciaoTJ