How should compilers sequence static initialization of objects/methods

Hello,


How does a compiler go about static initialization of constructors and
destructors , and does it account for dependances between them . How
would it do this or is it a breach in the standard to use such
dependant static methods.? I'm interesting in this because of a
problem I have encountered.


Say a there is a static initialized constructor and it depends on
another one. Then the order that the initialization is done could lead
to a runtime problem. Should a compiler account for this when
initializing prior to the main entry point, and if so how does it
determine the correct ordering, given that the two may be in different
files, or even, in a build environment, be linked in a different order


If not, any thought or suggestions on how this might be done ?


thanks in advance


R-L
--
Rachel-Louise Koktava
KittyCrap@severins-child.demon.co.uk
[Usually it generates anonymous routines that do the initialization,
and the linker somehow collects pointers to all those routines so the
program startup code can call them all. I gather that implicit
ordering dependencies are a chronic source of wierd and hard to
diagnose errors, and the standard advice about how to force a
particular order of initializers is "don't do that". Reports of
counterexamples if they exist would be appreciated, since I'm working
on that part of the linkers book. -John]

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