🚀 go-pugleaf

Eugene Radchenko (eugene@qsar.chem.msu.su) wrote:
: 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 [...]

I really don't think that the thousands of programmers who daily program
for operating systems that do not support virtual memory will happily let
ISO get away with defining the C++ language so that a conforming
implementation is not possible on their machines.

Incidentally, if what you are suggesting is what I think that you are
suggesting, you are imposing an implementation overhead that most people
will find unacceptable, since every object with static storage duration
would have to reside in a separate page.

That is unless you were going for translation-unit granularity, in which
case the "Deadly Embrace Initialisation", where the initialisation of
object A in translation unit X references object B in translation unit Y
and the initialisation of object C in translation unit Y references object
D in translation unit X, becomes a problem once more (which translation
unit do you initialise first ?) and you haven't solved the global
initialisation problem at all.

:                    If a unit is not referenced, it would not be
: constructed. Maybe it is really a desirable behavior (although draft
: standard says otherwise ;).

I don't want any such behaviour.  I rely on static duration instances of
single-instance classes to model libraries in DLLs.  The objects are not 
themselves referenced, but the constructors and destructors perform library
initialisation and cleanup.  I usually put the instances in their own
translation unit, along with _DLL_InitTerm(), as well.  Your proposed
alteration would break my programs, and, worse, leave me with no practical
alternative to achieve the same ends.

: 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.

Although not implemented as a stack, you will find that many
implementations already do this, because one favourite means of
implementing global initialisation is to construct at link time a list of
all static duration objectsi from all translation units and bind them into
the program.  At runtime this list is traversed from one end to the other 
to perform dynamic initialisation, and in the reverse direction to perform 
destruction.

Of course, a stack allows you to defer the ordering of the elements in the
list to run-time.

The main problem with global initialisation is that it is very hard to
describe in English the order in which the objects in a program should be
initialised, especially when individual translation units cannot know how
many other translation units will comprise the whole program, and what
static duration objects they will require.  So it's doubly hard to describe
it in a computer language.

The insight into implementation above may reveal a direction to pursue,
however.  If the total number of static duration objects in the whole
program is only known at link time, then the mechanism for controlling the
relative ordering amongst translation units belongs with the linker.

( Of course the C++ Working Paper has only a peripheral notion of a linker,
  and no way to control it at all.  I suspect that you'd have a hard time
  persuading people to come up with a standard mechanism for communicating
  directives to the linker from within the C++ language.  )


---
[ 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. ]