Article View: comp.std.c++
Article #2469Global Init/Shutdown: A solution (hopefully)
From: Eugene Radchenko
Date: Wed, 08 Nov 1995 18:01
Date: Wed, 08 Nov 1995 18:01
60 lines
3605 bytes
3605 bytes
Hi people!
I have got a few ideas concerning the static init/shutdown problem which I
would like to see discussed and criticized here.
The major problem is to ensure the right order of initialization (and
the inverse right order of destruction ;) between the translation units.
I think it can be solved by requiring that this initialization
really happens 'just' before the objects/functions in it are first accessed
- which may even happen before main() - when exactly is unimportant. If the
hardware architecture & OS support virtual memory (and now that Win95 is
out it means any general-purpose target platform worth programming for), it
can even be implemented in a way imposing no overhead once the program is
fully initialized. If a unit is not referenced, it would not be
constructed. Maybe it is really a desirable behavior (although draft
standard says otherwise ;). Alternatively, implementation could check for
the remaining uninitialized units and construct them just before caklling
main().
Otherwise (e.g. in embedded systems) we are probably limited to the
functions only, where the overhead ir equivalent to that required by the
static local objects.
Also, I think that the lifetime of the local static objects and global
translation units (i.e. sets of global objects defined in them) should
conform to the single stack-like semantics (actual implementation data
structure may vary). In other words, the object/unit is 'pushed' when its
construction starts (or ends). At the implementation-dependent moment after
main() returns, the implementation shutdown code starts 'popping'
objects/units from the stack and calling the appropriate destructors. This
way we guarantee that each object is destroyed in the environment at least
as rich as the one it was constructed in. (To observe this more completely,
it might be reasonable to push local statics between the objects from a
single unit. This increases the support memory requirements, though).
A fine point here is the local statics constructed during the
construction/destruction of other objects. Both ways of defining the
lifetime start (construction start/completion) seem wrong here. I don't
know which one is less wrong (especially if we work at the unit-as-a-whole
granularity).
One benefit of this approach is that it does not break the existing code.
Programs that did not use the interdependent statics will work as before,
while the game rules for others would be more clear and helpful.
Best regards Genie
--
--------------------------------------------------------------------
Eugene V. Radchenko Graduate Student in Computer Chemistry
E-mail: eugene@qsar.chem.msu.su Fax: +7-(095)939-0290
Ordinary mail: Chair of Organic Chemistry, Department of Chemistry,
Moscow State University, 119899 Moscow, Russia
***************** Disappearances are deceptive *******************
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID:
<AI-HDemqX1@qsar.chem.msu.su>Path:
arc1-ca.pugleaf.net!128.32.155.1!mattShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!128.32.155.1!matt From: "Eugene Radchenko" <eugene@qsar.chem.msu.su> Newsgroups: comp.std.c++ Subject: Global Init/Shutdown: A solution (hopefully) Date: 08 Nov 1995 18:01:14 GMT Organization: Lab. of Org.Synth., MSU Approved: matt@physics2.Berkeley.EDU (Matt Austern) Message-ID: <AI-HDemqX1@qsar.chem.msu.su> NNTP-Posting-Host: physics2.berkeley.edu