Re: GLib "next cycle" update

[Kean Johnston <kean johnston gmail com>]

On 9/19/2011 3:36 PM, Alexander Larsson wrote:
> On Sun, 2011-09-18 at 13:11 -0400, Ryan Lortie wrote:
> >   - use a __attribute__((constructor)) approach
I see you raised the portability concern, forget my previous mail

> Unfortunately this is a pragma, which doesn't expand macro arguments, or
> is possible to put in a macro. The only way to do this as an API is with
> #include, so you'd do
>
> #include<glib/glib-constructor-pre.h>
> G_DEFINE_CONSTRUCTOR (my_constructor);
> #include<glib/glib-constructor-post.h>
>
> Which does something like:
> glib-constructor-pre.h:
>
> #define G_DEFINE_CONSTRUCTOR(func) \
>    static void _glib_constructor (void) { \
>      (func) (); \
>    }
> glib-constructor-post.h:
> #pragma init(_glib_constructor)
>
> Which, apart from looking ass, only works with one constructor per file.
Any time you have to resort to hacks like this, it's time to rethink the 
approach IMHO. I need to go back and read the actual problem more carefully 
but that just does not look sustainable (I know you weren't suggesting that 
approach, merely pointing out a work-around).

> >       - use internal rigging to ensure dependent inits are called first
> >         or just use one big initialisation function that does it in the
> >         right order
>
> I think this is the right approach, its just plain more reliable and
> debuggable.
The gentleman who taught me C ... oh ... 25 years or so ago, made a very 
wise statement: code for your debugger. He's right. When it comes to 
maintaining code, especially when maintainers come and go, the less 
trickery one resorts to and the simpler one writes code, the easier it is 
to debug, and therefore maintain.

Kean