ordering of constructors

[Matt Austern]

On Apr 12, 2004, at 10:01 AM, Phil Edwards wrote:

> On Fri, Apr 09, 2004 at 09:18:11PM -0400, Daniel Jacobowitz wrote:
>> On Sat, Apr 10, 2004 at 01:34:44AM +0200, Gabriel Dos Reis wrote:
>>>
>>> Are you saying GCC never delays dynamic initializations until a point
>>> int main()?
>>
>> I don't believe it does for any file scope variable, which will be
>> initialized before main - or on systems where we can't do that, the
>> initializations will be emitted inside main but before the first
>> statement of main (? or a wrapper function placed around main?
>
> For modern (read, ELF SysV-ish) systems, it's done by the loader  
> before main.
>
> For the rest, it's done by a generated __main function, and we emit a  
> call to
> __main() as the very first thing in main(), before we've analyzed or  
> emitted
> anything else in main().  The actual contents of __main are determined  
> at
> link time.  The user has no control over this, even if he writes
>
>   int main()
>   {
>     do_something_to_announce_the_beginning_of_main_but_
>       
> without_using_any_dyn- 
> init'd_variables_that_would_force_their_creation();
>
> our code will still slide in there first.  They will still be created
> before any user-visible main() statement.
>
> So, no, we never delay dynamic initialization until after main()  
> begins,
> as far as the user can tell.

But it's a little more complicated than that, since some of this is done
by the dynamic loader and not by the compiler.

On OS X, if a program uses dynamic libraries (and I'm not just talking
about programmatically loaded libraries), we have lazy binding and
some initialization is delayed until after the start of main().

Libraries that the program manually loads and unloads are a whole
other mess.  The Itanium C++ ABI document discusses how to
handle them.

			--Matt