🚀 go-pugleaf

>>>>> On Thu, 12 Oct 1995 18:49:39 -0700, Mike Stump <mrs@cygnus.com> said:

    >> From: langeng@world.std.com (Language Engineering Corporation)
    >> Message-Id: <DFKMsG.3Cp@world.std.com> Date: Wed, 27 Sep 1995
    >> 15:53:03 GMT
    >> 
    >> My guess that the data structures required to catch exceptions
    >> properly are initialized as by static initializers, and that I
    >> have managed to get some of my static initializers called
    >> before the exception handling mechanism is ready.

    Mike> Bingo!  Good guess, I am impressed.

    >> Is there any way I can control the order of static initializers
    >> in order to ensure that the exception handling stuff is
    >> initialized first?

    Mike> Nope.

    Mike> The right solution, is to add the EH data into a section for
    Mike> the EH data.  This would be a link time thing.  However,
    Mike> this isn't a complete solution, as shared libraries aren't
    Mike> covered in this case.

I don't understand what this means.  I could live with static linking
if there was a way to work around this problem.  Is the EH data
section solution something that I can do?  

    Mike> If anyone has a really good design they're willing to share,
    Mike> let me know.  I'll have to think about it some more.

The inability to control order of static initialization sounds like a
C++ language limitation to me.  I don't know if you are familiar with
the hack that I was shown to control the order of my own static
initializers.  Each module that has order-dependent static
initialization defines a class.  The ctor for this class performs the
static initialization.  A static data member of the class prevents
guards against the initialization being done more than once.  If
module B needs to ensure that module A's initialization is done before
its own initialization, it declares a static instance of module A's
initialization object early in module B.  The fact that C++ does
ensure that initializers within a module are called in order of
appearance in the module causes module A's initialization function to
be called before the following statics in module B.

If classes like this could be provided for the library modules which
need static initialization, e.g. exception handling, iostreams, etc.,
then people like me could hack around problems like this by declaring
static instances of these classes where necessary.

-Alec

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Alec Wysoker
Language Engineering Corporation
385 Concord Avenue
Belmont, MA  02178
alec@hq.lec.com
v: (617)489-4000x729
f: (617)489-3850