Re: How to run code before global constructors?

From: David Schwartz (
Date: 07/25/03

Date: Thu, 24 Jul 2003 16:19:53 -0700

<> wrote in message

> In <bfpcm6$vnr$> "David Schwartz"
<> writes:

> >Not easy. The constructors call low-level code that is heavily
> >micro-optimized. An extra test for initialization would destroy the
> >point of the signal handler. The code is designed to fault if it's not
> >initialized and the signal handler handles the fault by doing the
> >initialization.

> Sorry, but when you have lots and lots of global objects in your C++ code,
> there must have been something wrong from the start.

    Agreed. The problem is, it only takes one. I'm trying to write code that
would be part of a module and having a module that prohibits other modules
from constructing global objects would be too painful.

> > An analogy that might help is if you imagine a program that has two
> >run-time modes. In one run mode, a piece of inline low-level assembly
> >called from many places has to increment a variable and in the other run
> >mode it has to decrement it. So instead of an increment or decrement
> >instruction, you put an illegal opcode. In the SIGILL handler, you check
> >which run mode you're in and replace the illegal opcode with the correct
> >one.

> > This works perfectly until a global constructor calls something that
> >uses this inline code.

> I still can't see why this structure should prevent the straight forward
> solution:

> a) write global function that does the signal handler initialisation
> and records the fact that the signal handler is installed in a
> global static variable (ouch! but you've started it ;-)
> b) add a call in every ctor, which is globally called to that function
> before any real work is done.

    Even if I only have one constructor that's globally called, if it's
called non-globally billions of times, I pay the penalty on each call. This
is a micro-optimization I'm talking about.

> If you have too many global objects to do that, throw it away. Really.

    Would you like to use a C++ module if it had the restriction that you
couldn't create any global objects at all? Would you use a string class that
didn't allow you to have any global strings?

    I agree with you, global objects are bad. But I also thing that it would
be annoying to have a low-level library that couldn't be called in a
constructor that might be used on a global object.

    I'm dealing with code that may get called three times on every memory
allocation/deallocation. Perhaps more if it's an allocation for an object
that contains certain types of sub-objects. So I'm really concerned with