Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Jakob Bohm <egenagwemdimtapsar@jbohm.dk>
Newsgroups: comp.lang.c++
Subject: Re: Pre-main construction order in modules
Date: Tue, 1 Apr 2025 06:29:14 +0200
Organization: Privat
Lines: 55
Message-ID: <vsfq2q$26s1t$1@dont-email.me>
References: <vsb12i$2mv42$1@dont-email.me> <vsbl21$1jsvi$1@dont-email.me>
 <vsbo2p$1p5ov$1@dont-email.me> <vse8sj$f9o2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 01 Apr 2025 06:29:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0699a4fa08841fa214c731a2df9617d6";
	logging-data="2322493"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+ZX7ZejISqSFqh2UPemTjN9T0hVNADnHkgF9quiOBqGA=="
Cancel-Lock: sha1:3cNtU+pKBIoH0LXf36S4qPFGTeI=
In-Reply-To: <vse8sj$f9o2$1@dont-email.me>
Content-Language: en-US
X-Mailer: Epyrus/2.1.3

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.