🚀 go-pugleaf

In article <199509282107.RAA13781@mv.mv.com>,
MichaelFurman <engr@gssi.MV.COM> wrote:

>   If initialization can be "deferred to any point in time before the first
>use a function or object defined in that translation unit" (as described in
>ARM and I believe - I do not have it with me - in draft standard) - I can
>not implement this strategy at all because in main part of software I do not
>know which translation units - drivers - I have. It seams to me that I can
>not avoid recompilation of some file and I have to change that file each
>time I implement a new driver.
>
>My questions:
>
>1. What is a reason of allowing it to be deferred.

I'd think the reason is to allow dynamic linking. If the initialization
would have to be done always before main(), dynamic linking would not be 
possible, because those dynamically linked modules can't generally be 
initialized before the call to main().

Also, the requirement allows the system to optimize initialization
of different translation units by not loading the entire program into
memory on startup (which can be very slow), but
instead only loading everything the translation unit containing 
main() needs, and then initializing each translation unit when the
first use of the translation unit is done. On large programs, most of
the time used for the startup could be spent in loading all the translation
units to memory (most of which don't ever get used) otherwise. 

>2. May be I just don't see how to implement it better, without relying on
>this unsupported fact (actually all compilers I know do it before calling 
>main).

I don't think there's a (portable) way to force a compiler to 
initialize everything before main(). I suspect it couldn't be
implemented on all platforms (with primitive linker support).
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.
---
[ 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. ]