Thread View: comp.std.c++
2 messages
2 total messages
Started by Eugene Radchenko
Wed, 08 Nov 1995 18:01
Global Init/Shutdown: A solution (hopefully)
Author: 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. ]
Re: Global Init/Shutdown: A solution (hopefully)
Author: Robert Coie
Date: Fri, 10 Nov 1995 01:15
Date: Fri, 10 Nov 1995 01:15
33 lines
1912 bytes
1912 bytes
In article <AI-HDemqX1@qsar.chem.msu.su>, "Eugene Radchenko"
<eugene@qsar.chem.msu.su> wrote:
: 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.
[snip]
I don't see how this can be guaranteed. The simplest pathological case I
can think of (although trivial) is:
struct A { A(); };
A stA;
A::A() {}
I can't see how you can guarantee that the initialization of stA occurs
before the call to the constructor used to initialize it. The burden on
insuring that static objects are properly constructed before they are
referenced must fall, in the end, on the programmer, as far as I can see.
Robert Coie
Implementor, Intrigue Corporation
rac@intrigue.com
---
[ 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. ]
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads