Re: How should compilers sequence static initialization of objects/methods

>>>>> Rachel-Louise Koktava <KittyCrap@severins-child.demon.co.uk> writes:


  > How does a compiler go about static initialization of constructors and
  > destructors


As John said, it generates anonymous routines that call them. Older
object file formats use a pre-linker to scan the object files, look
for functions that match a pattern, and walk through them at program
start and end. SVR4ish ELF systems have .init and .fini sections
where you can stick things to be run at load and unload times. In
GCC, see the collect2 program and crtstuff.c, respectively.


  > and does it account for dependances between them.


In general, no. This was an open question in the C++ committee for a
long time, and nobody came up with a good solution, so we punted.


The standard trick people use to assure that code is initialized
before it's used is the one used by iostreams; namely, create some
dummy class to do your initialization and define a static variable of
that type in your header, so that everyone that includes your header
gets one. Then each of those translation units will run your
initializer before any of its own. This is, of course, a kludge.


Having said that:


When I was using Borland C++ in 1992, I remember it having a #pragma
init that let you run arbitrary code during initialization, and
control what order it was run in. I don't know if that allowed you to
control order of initialization as well.


The development version of g++ has support for


  A a __attribute__ ((init_priority (234)));


to control order of initialization, again using numerical priorities.


In general, though, the answer seems to be "don't do that".


Jason

Return to the comp.compilers page.
Search the comp.compilers archives again.