Re: How to run code before global constructors?
From: David Schwartz (davids_at_webmaster.com)
Date: Thu, 24 Jul 2003 16:19:53 -0700
<Ulrich.Teichert@gmx.de> wrote in message
> In <firstname.lastname@example.org> "David Schwartz"
> >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
> 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
> > 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
> 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