When does static initialization occur?

[JohnQ]

From the other posts, they say that program load and static
initialization (probably) occur during A. So, we have:

A.) Program load and (probably) static initialization.
B.) Dynamic initialization, runtime library initialization, registering of
global destructors (?).
C.) main().

"Sort of. The runtime library generally uses the same
initialization mechanisms as the rest, and does nothing special.
(This isn't quite true, and some elements from C, such as stdin,
probably do require special handling.) And there's normally no
need to "register" destructors; exit uses the same means of
finding them that the initialization did."

I probably got the terminology "registering destructors" wrong. I was just
remembering what I "learned" from the LibCTiny documentation. Here'a a quote
from that doc:

"All things considered, getting static constructors to work in LIBCTINY was
relatively easy. It was mostly a matter of defining the right data segments
(specifically, .CRT$XCA and .CRT$XCZ), and calling _initterm from the
correct spot in the startup code. Getting static destructors to work was a
bit trickier.
Unlike the function pointer array that the compiler and linker conspire to
create for static constructors, the list of static destructors to call is
built at runtime. To build this list, the compiler generates calls to the
atexit function, which is part of the Visual C++ runtime. The atexit
function takes a function pointer and adds the pointer to a first-in,
last-out list. When the EXE or DLL unloads, the runtime library iterates
through the list and calls each function pointer."

(LibTinyC is described in an early Dr. Dobbs article and an updated article
(and code) on the web. The article is "Reduce EXE and DLL Size with
LIBCTINY.LIB" by Matt Peitrek).

I'm not sure I'd use it in production code (because I don't have the
required low level knowledge to be confident about it or confidence that I'd
be able to fix it if it "breaks" unexpectedly) but it sure was fun to play
with one day (hehe, actually, I'm still building small test code under that
"environment").

Personally, I don't think it would be out of line to suggest that the "entry
point" be accepted as being under the control of the programmer instead of
just everything after main. That would increase mechanism and decrease
policy in the standard a little. (Now my question is "what is the difference
between a hosted and non-holsted C++ implementation?". Somehow, I think it's
related?).

John