Re: GLib "next cycle" update

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

G_DEFINE_CONSTRUCTOR (my_constructor);

Which does something like:

#define G_DEFINE_CONSTRUCTOR(func) \
   static void _glib_constructor (void) { \
     (func) (); \
#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
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]