Re: GTK+ team irc meeting

[Dave Benson <daveb idealab com>]

Hi,

Unfortunately, I have to be out-of-town this weekend,
but i would like to call attention to one seeming regression
of glib 2.6.1:  the inlining apparatus no longer works
as advertised.

This has been reported as bug 165852, but i'm afraid
it starts out with a red-herring: a user misusing G_INLINE_FUNC
instead of inline.

But there appears to be a very real regression... the header file
gutil.h describes the intended usage:
/* inlining hassle. for compilers that don't allow the `inline' keyword,
 * mostly because of strict ANSI C compliance or dumbness, we try to fall
 * back to either `__inline__' or `__inline'.
 * G_CAN_INLINE is defined in glibconfig.h if the compiler seems to be 
 * actually *capable* to do function inlining, in which case inline 
 * function bodies do make sense. we also define G_INLINE_FUNC to properly 
 * export the function prototypes if no inlining can be performed.
 * inline function bodies have to be special cased with G_CAN_INLINE and a
 * .c file specific macro to allow one compiled instance with extern linkage
 * of the functions by defining G_IMPLEMENT_INLINES and the .c file macro.
 */

But alas, ifdef G_IMPLEMENT_INLINES, then G_CAN_INLINE remains defined,
(That changed from 2.6.0 to 2.6.1) and so *every header included is implemented*.

This causes multiple definition errors of glib inline functions
like g_bit_nth_lsf() if you use the inlining apparatus.


On the other hand, it's not like #undef G_CAN_INLINE is free:
every inline function will be non-inlined, even throughout your
implementation.  Therefore, i'd recommend people
only #define G_IMPLEMENT_INLINES from a file that includes no other code.

That would a change of recommendations from earlier glibs, but a sensible one,
and one that has always been beneficial for efficiency.

- dave

On Mon, Mar 28, 2005 at 12:12:43AM -0500, Matthias Clasen wrote:
> Since some people may be away on Easter Monday, lets move
> the meeting to Tuesday.
> 
> The meeting is intended for the GTK+ team, but everybody is 
> welcome to come and listen. The meeting logs will be posted 
> on the GTK+ website (http://www.gtk.org/plan/meetings).
> 
>  Place: irc.gnome.org:#gtk-devel
>  Time: 21:00 UTC (16:00 EST), Tuesday March 29
> 
> Possible Agenda items:
> - Timeframe and patches for 2.6.5
> - Where do we stand wrt to prototypes for 2.8 features ?
> 
> 
> Matthias
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

--