Re: Pre-main construction order in modules

On 2025-03-31 16:29, James Kuyper wrote:

On 30.03.2025 18:30, Muttley@DastardlyHQ.org wrote:

On Sun, 30 Mar 2025 10:38:57 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:

Section 6.9.3.3 does in fact impose many constraints on the sequence in
which non-local objects with static storage duration get initialized.
However, all of the sequence requirements are only between objects
defined in the same translation unit. Also, it's implementation-defined
which of those initializations occur before the start of main().

>
Initialising global objects before main is an absolute must otherwise how
are you expected to use them safely? They're not in the code for decoration.

 "If it [initialization] is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as the variable to be
initialized.47 It is implementation-defined in which threads and at
which points in the program such deferred dynamic initialization
occurs." (6.9.3.3p5).
 Therefore, what you need to do is make sure that the object has been
initialized is to access it from a function defined in the same
translation unit.
 

The literalist reading of that wording fails miserably if a real world program uses a global constructor/initializer to cause some desired imperative effect outside the C++ runtime state.  Examples include setting the CPU clock frequency of a small system, outputting some kind of welcome message to the human user etc. etc.
However treating the standard text as an imperfect description of traditional compiler techniques used for 2nd. Edition compilers makes
much more sense .  Those guarantee that all included global objects
are constructed before the first line of the main/init function of the
linker output unit (program, dll, driver, whatever) and destructed after the last line of the main/cleanup function of the same .  Even if either of those functions are implicit default empty functions .   Just like if
those globals were member objects of an implied program class where main/init/cleanup are member/constructor/destructor functions .
Note that my previous paragraph accepts the possibility of some global
objects getting optimized away completely along with their compilation unit by things like using a static library containing those compilation units .
   Enjoy
   Jakob
--
Jakob Bohm, MSc.Eng., I speak only for myself, not my company
This public discussion message is non-binding and may contain errors
All trademarks and other things belong to their owners, if any.