ordering of constructors

[Matt Austern]

On Apr 9, 2004, at 4:39 PM, Gabriel Dos Reis wrote:

> Joe Buck <Joe.Buck@synopsys.com> writes:
>
> | On Fri, Apr 09, 2004 at 10:52:00AM -0400, Daniel Jacobowitz wrote:
> | > On Fri, Apr 09, 2004 at 03:33:20PM +0200, Gabriel Dos Reis wrote:
> | > >   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*.
> | >
> | > 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.  Instead, we're before main executing global
> | > constructors.
> | >
> | > To honor your interpretation of that paragraph, we would have to 
> check
> | > at the beginning of every external function in every translation 
> unit
> | > containing static variables whether they had been initialized yet,
> | > which would be prohibitively expensive - and I'm pretty sure we 
> don't
> | > do that.
> |
> | It's worse than that; an attempt to provide the guarantee before main
> | is called fails in cases where constructors in file A.cpp depend on
> | the construction of objects in B.cpp and vice versa: an attempt to
> | provide the guarantee would cause a deadlock.
>
> I don't see why that is different from what happens when the dynamic
> initialization is delayed until main() as described by 3.6.2/3.

Arguably it's a bad thing that the standard gives implementations
freedom to do that.  The more I read this part of the standard the
less happy I am with it.

			--Matt