In article <1993Nov5.172022.2026@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>ARM 3.4 (p. 19) notes that
>
>    The default initialization of all static objects to zero (sec. 8.4) is
>    performed before any dynamic initialization.
>
>ARM 8.4 (p. 150) says that
>
>    Variables with storage class static that are not initialized are
>    guaranteed to start of as 0 converted to the appropriate type.  So are
>    members of static class objects.
>
>I have always interpreted this to mean that the default initialization to
>zero for static objects only applies to objects without initializers.  ARM
>3.4 calls it "default" initialization, and ARM 8.4 refers to objects that
>"are not initialized."
[]
>Sez the ARM:
>
>    Because the static initialization to 0 takes place before dynamic
>    initialization, there are no further possibilites for the values of x
>    and y.
>
>My reading of 8.4 tells me that x and y have explicit initializers and
>should hence not be statically initialized to 0.  Therefore:
>
>    1.  Did I miss something somewhere, or is this a contradiction in the
>        ARM?

 Yes.

>    3.  Anybody know what the standard is likely to look like in this area?
>        I know that the committee has studied the problem of controlling
>        the initialization order of static objects.

 Yes. ALL static objects will be initialised to zero first,
and then, if they are integral with constant expressions for initialisers,
to those values, as if at compile time.

 Then, dynamic initialisations will be performed,
including invocation of default constructors where no explicit
initialiser is given.

 At least, thats a simplified view of the way I see it.
(..how does one initialise a reference to zero?)

 Some initialisations are classed as 'dynamic' that really
ought to be 'like constants' (eg. pointers to addresses of externals).

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <1993Nov5.172022.2026@cs.brown.edu> sdm@cs.brown.edu (Scott
Meyers) writes:

|> ARM 3.4 (p. 19) notes that

|>     The default initialization of all static objects to zero (sec. 8.4) is
|>     performed before any dynamic initialization.

One could interpret this to mean *all* static objects, including those
which have explicit initializers.  While one might be excused for not
interpreting it this way - should 'int i = 3' really mean initialize i
to 0, then assign 3 to it - further reading in the ARM, particularly
the example cited below, would suggest that this is in fact the case.
(Of course, Scott's next quote would suggest just the opposite.)

|> ARM 8.4 (p. 150) says that

|>     Variables with storage class static that are not initialized are
|>     guaranteed to start of as 0 converted to the appropriate type.  So are
|>     members of static class objects.

|> I have always interpreted this to mean that the default initialization to
|> zero for static objects only applies to objects without initializers.  ARM
|> 3.4 calls it "default" initialization, and ARM 8.4 refers to objects that
|> "are not initialized." Technically, I believe this means that this
|> definition

|>     int x;

|> and this definition

|>     int x = 0;

|> are not equivalent, because the former will be "preinitialized" before any
|> dynamic initialization is performed, but the latter cannot be
|> preinitialized and must wait until after all preinitializations (in all
|> translation units) have been completed.  It is my understanding that the
|> ANSI/ISO committee is rewording things so that all "C-like" initializations
|> qualify for preinitialization, so the two definitions above would be
|> semantically equivalent.

I believe that you are not the first person who has held this belief.

|> That notwithstanding, the example in ARM 3.4 (p. 20) confuses me:

|>     // file 1:
|>     extern y;           // can the type really be omitted?
|>     int x = y + 1;

|>     // file 2:
|>     extern x;
|>     int y = x + 1;

|> Sez the ARM:

|>     Because the static initialization to 0 takes place before dynamic
|>     initialization, there are no further possibilites for the values of x
|>     and y.

|> My reading of 8.4 tells me that x and y have explicit initializers and
|> should hence not be statically initialized to 0.  Therefore:

|>     1.  Did I miss something somewhere, or is this a contradiction in the
|>         ARM?

It depends on how you interpret your first quote.  At the very least,
it is an ambiguity.

|>     2.  What is the current state of the practice regarding
|>         "preinitialization" of static objects?  Do most compilers perform
|>         all "C-like" initializations at compiletime?

All compilers I know of actually separate initializations into
'static' initialization and 'dynamic' initialization.  Static
initialization can be performed without executing code, and
corresponds roughly to C-like initializations.  In all of the
implementations I've seen, static initialization takes place
'magically', before any code (including initialization code) is
executed.

In article <1993Nov5.172022.2026@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>ARM 3.4 (p. 19) notes that
>
>    The default initialization of all static objects to zero (sec. 8.4) is
>    performed before any dynamic initialization.

Watch out here Scott.  There's at least one hidden flaw in that rule.
It requires that something be done which (according to the type system)
can't be done (at least in some cases).  There's no such thing as a NULL
reference, so you can't "zero-initialize" a reference.

(I think I have to give credit to Skaller for finding this one.  My re-
collection is that he mentioned it first.)

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

ARM 3.4 (p. 19) notes that

    The default initialization of all static objects to zero (sec. 8.4) is
    performed before any dynamic initialization.

ARM 8.4 (p. 150) says that

    Variables with storage class static that are not initialized are
    guaranteed to start of as 0 converted to the appropriate type.  So are
    members of static class objects.

I have always interpreted this to mean that the default initialization to
zero for static objects only applies to objects without initializers.  ARM
3.4 calls it "default" initialization, and ARM 8.4 refers to objects that
"are not initialized." Technically, I believe this means that this
definition

    int x;

and this definition

    int x = 0;

are not equivalent, because the former will be "preinitialized" before any
dynamic initialization is performed, but the latter cannot be
preinitialized and must wait until after all preinitializations (in all
translation units) have been completed.  It is my understanding that the
ANSI/ISO committee is rewording things so that all "C-like" initializations
qualify for preinitialization, so the two definitions above would be
semantically equivalent.

That notwithstanding, the example in ARM 3.4 (p. 20) confuses me:

    // file 1:
    extern y;           // can the type really be omitted?
    int x = y + 1;

    // file 2:
    extern x;
    int y = x + 1;

Sez the ARM:

    Because the static initialization to 0 takes place before dynamic
    initialization, there are no further possibilites for the values of x
    and y.

My reading of 8.4 tells me that x and y have explicit initializers and
should hence not be statically initialized to 0.  Therefore:

    1.  Did I miss something somewhere, or is this a contradiction in the
        ARM?

    2.  What is the current state of the practice regarding
        "preinitialization" of static objects?  Do most compilers perform
        all "C-like" initializations at compiletime?

    3.  Anybody know what the standard is likely to look like in this area?
        I know that the committee has studied the problem of controlling
        the initialization order of static objects.

Scott