Re: Pre-main construction order in modules

On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote:

On Mon, 31 Mar 2025 11:49:23 +0300
Paavo Helde <eesnimi@osa.pri.ee> wibbled:

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.

>
Initializing global objects before main is not possible with
demand-loaded dynamically loaded libraries.

 Well obviously, but thats not what I'm talking about. If myobj() is constructed
in a linked .o file I expect it to be available and ready in main(). If not
then when? Or are you just supposed to guess or hope for the best?

The standard does not talk specifically about dynamic libraries, so the same rules apply for the main program. This means the same quote you snipped is relevant to your myobj as well:
"If [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."
The keyword here is "non-initialization use". If you access your myobj from main() it would be a non-initialization use, which is guaranteed to trigger the needed initialization if needed, so everything will work fine.