ordering of constructors

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

| 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.

Do you believe a core issue should be raised?

I must confess I don't see why that is bad.  
As I understand the paragraph, if the dynamic initialization is
delayed until main(), then there is a guarantee that a non-local
object is initialized before any function defined in the same
translation unit is used.  In particular, this makes the guarantee
that if you use a dynamically loaded unit (which the standard formally
does not speak about, but exists in practice), then the act of loading
that unit will provoke the initialization of contained non-local
objects before any function from that translation unit is used.  
What is wrong with it?

-- Gaby