Re: inline and glib.h (was Re: ObjC and `glib.h')

[Tim Janik <timj gtk org>]

On 3 Oct 1998, Guillaume Laurent wrote:

> Tim Janik <timj@gtk.org> writes:
> 
> > > #      define inline /* don't inline, then */	<---- potential trouble here
> >          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > how would that cause problems for a compiler that doesn't understand
> > "inline" at all?
> 
> It wouldn't, I didn't make myself clear, sorry. The C compiler is not
> the problem, a C++ compiler is, though.
> 
> > > It seems trouble would occur if glib is configured for a C compiler
> > > which absolutely does not understand "inline", and glib.h is included
> > > from C++.
> > 
> > hm, could you extend on what the trouble actually is and provide a test
> > case (including information about the system and the C/C++ compiler
> > you are running)?
> 
> Suppose your C compiler does not understand 'inline'. glib.h is
> configured to #define 'inline' away. If you happen to include glib.h
> with such a configuration from C++, where 'inline' is standard, you're
> in trouble. Tero and some Gtk-- users ran into this problem recently,
> due to an old glibconfig.h lying in the wrong place.

the actuall problem was the stale glibconfig.h then.
the current scheme works fine, even with C++, assuming there is no
compiler out there that supports "inline" only for C++ and wouldn't
know about "inline" in C mode.

> 
> I suppose adding
> 
> #ifdef __cplusplus
> #define G_HAVE___INLINE 1
> #define G_HAVE___INLINE__ 1
> #define G_HAVE_INLINE 1
> #endif

unless there is such a brain-damaged compiler out there, this would be
superfluous. in any case, you'd only need the G_HAVE_INLINE 1 define.

> would do the trick...
> 
> BTW, why are g_error(), g_message() and g_warning() defined with a
> plain 'inline', like this :
> 
> static inline void
> g_error (const gchar *format,
> 	 ...)
> 
> while everywhere else in glib.h, G_INLINE_FUNC is used ?

the functions declared as G_INLINE_FUNC functions are ones that make
actuall use of compiler that support inlining. G_INLINE_FUNC usually
expands to static inline for inlining aware compilers, and for gcc
it expands to extern inline if gcc is run with at least -O1, since
gcc can't do inlining without optimization.
if a non inline aware compiler is used, or gcc without optimization,
the functions are simply declared as extern and a glib implementation
is provided.

for g_error, g_warning and g_message() we have to proceed a little different
since they need to always be expanded within the c-source file currently
compiled and can't be implemented as extern functions because they do some
little macro magic regarding G_LOG_LEVEL. for non inline aware compilers,
they are just declared as static functions, and for gcc we always use
varargs macros.


> 
> -- 
> 					Guillaume.
> 

---
ciaoTJ