ordering of constructors

[Daniel Jacobowitz]

On Sat, Apr 10, 2004 at 01:34:44AM +0200, Gabriel Dos Reis wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> | On Fri, Apr 09, 2004 at 03:33:20PM +0200, Gabriel Dos Reis wrote:
> | > Daniel Jacobowitz <drow@false.org> writes:
> | > 
> | > | On Fri, Apr 09, 2004 at 02:15:24PM +0200, Gabriel Dos Reis wrote:
> | > | > For example, it can be something like
> | > | > 
> | > | >    A.H:
> | > | >    struct A { some constructor ... };
> | > | >    extern A a;
> | > | >    void make_sure_a_is_constructed();
> | > | > 
> | > | >    A.C
> | > | >    A a;
> | > | > 
> | > | >    void make_sure_a_is_constructed() { /* empty */ }
> | > | > 
> | > | > 
> | > | > 
> | > | >    B.H:
> | > | >    #include "A.H"
> | > | >    struct B { ... }
> | > | > 
> | > | >    B::B()
> | > | >    {
> | > | >       make_sure_a_is_constructed();
> | > | >       // use a...
> | > | >    }
> | > | > 
> | > | >    B.cc;
> | > | >    B b; 
> | > | >    
> | > | > 
> | > | > 
> | > | > The call to make_sure_a_is_constructed(), will provoke the
> | > | > initialization of a, before that function is executed.  
> | > | 
> | > | Er... for those of us ignorant, could you explain why this assures
> | > | anything?
> | > 
> | > 3.6.2/3
> | > 
> | >   It is implementation-defined whether or not the dynamic
> | >   initialization (8.5, 9.4, 12.1, 12.6.1) of an object of namespace
> | >   scope is done before the first statement of main. If the
> | >   initialization is deferred to some point in time after the first
> | >   statement of main, *it shall occur before the first use of any
> | >   function or object defined in the same translation unit as the
> | >   object to be initialized*. 
> | > 
> | > (emphasis is mine).
> | 
> | Does that answer the question?  I don't believe that it does.  In this
> | case, the initialization is _not_ deferred until after the first
> | statement of main. 
> 
> 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?  I don't
remember; I think collect2 is involved.  I'm sure someone can correct
me).

For block scope variables, we used to initialize them on entry to the
function.  It certainly appears that we still do that; see "guard
variable" in the v3 ABI.  Right now that means we emit:
        cmpb    $0, _ZGVZ3foovE10static_bar
        jne     .L2
        movl    $_ZZ3foovE10static_bar, (%esp)
        call    _ZN3BarC1Ev
        movb    $1, _ZGVZ3foovE10static_bar

That's not even thread-safe; I think there may be a PR about this
somewhere?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer