Re: GTK+ team irc meeting
- From: Dave Benson <daveb idealab com>
- To: gtk-devel-list gnome org
- Subject: Re: GTK+ team irc meeting
- Date: Sun, 27 Mar 2005 23:39:35 -0800
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
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.
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 ?
> gtk-devel-list mailing list
> gtk-devel-list gnome org
] [Thread Prev