Re: Pre-main construction order in modules

On 4/1/25 00:29, Jakob Bohm wrote:

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

...

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

The wording describes what C++ does and does not require of an
implementation. What actual implementations do is a different issue. If
an implementation doesn't do what's required of it, it's non-conforming.
If a program expects more than is required, the behavior of that code is
undefined, which includes the possibility that the code will work
exactly as intended if translated by an implementation that does, in
fact, do more than what is required.

However treating the standard text as an imperfect description of
traditional compiler techniques used for 2nd. Edition compilers makes
much more sense .

No, that does not. The standard was never intended as a description of
how compilers actually work, it was always intended to be a description
of requirements on how they should work.