Re: [PATCH 00/13] Improved introspection support

[Simón Pena <spenap gmail com>]

On 30/07/10 10:18, Víctor M. Jáquez L. wrote:
> On Thu, Jul 29, 2010 at 12:20:40PM +0200, Juan A. Suarez Romero wrote:
>> On Wed, 2010-07-28 at 23:06 +0200, Simón Pena wrote:
>>> * Replacing alias defined with macros, as they can't be introspected,
>>>   using "inline" functions instead.
>>>
>>>   This has been done in two steps: first, macros were replaced with
>>>   functions, which works fine. Then, those functions were marked as
>>>   "inline" following [1], declaring the functions with "extern", and
>>>   defining them with "inline". 
>>
>>
>> It is common use to declare and define inline functions in the same
>> header file.
>>
>> You can find a lot of examples using google's code search.
>>
>> The good point about declaring them in .h instead of .c is that it
>> resembles more to #defines, as you see the declaration and what it does
>> in the same place.
>>
>> But I would like to hear other opinions.
> 
> In a quick glance, I found a couple issues:
> 
> 1) You have to add the compiler flag -std=c99, because some gcc compilers
>    versions don't use c99 by default.

configure.ac has already dealt with that:

CFLAGS+=" ${WARN_CFLAGS} -Wmissing-declarations -std=c99 "

> 2) The inline functions are commonly used inlined :D, inside the .h file if
>    they are supposed to be exported. Take a look to this file used in gst-dsp:
> 
>    http://github.com/felipec/gst-dsp/blob/master/dsp_bridge.h

Defining the methods that way works in a situation with no bindings
involved, like in the grilo-plugins case. However, g-ir-scanner fails to
extract the inline functions, and the resulting .so file doesn't have
the symbols, either.

There's a gcc flag, "-fkeep-inline-functions", which should be of help.
According to the manual:

>In C, emit "static" functions that are declared "inline" into the
>object file, even if the function has been inlined into all of its
>callers.
>This switch does not affect functions using the "extern inline"
>extension in GNU C89. In C++, emit any and all inline functions into
>the object file.

However, even when using that flag, the inlined functions doesn't appear
in the resulting .so file. And, with the functions not being exported, I
don't see how would the introspection mechanism be able to access them.

I don't see many options here: it looks like the patches I sent don't
success getting the functions inlined: looking at the plugins' object
code shows that those functions are still present. On the other way,
succeeding in inlining those functions implies that we loose the
introspection.

So, in my opinion, we might as well go for "first class" functions, with
no inlining. Does it affect performance that much? (I would provide new
patches for that)

Cheers,

Simon