NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/cplus/18777

Text File | 1993-01-06 | 3.0 KB | 76 lines

Path: sparky!uunet!cs.utexas.edu!ut-emx!jamshid
From: [e-mail] (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: Static global initialization outside of main() legal?
Message-ID: <[e-mail]>
Date: 6 Jan 93 22:17:12 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: The University of Texas at Austin; Austin, Texas
Lines: 64

In article <[e-mail]> [e-mail] (John MAX Skaller) writes:
>In article <[e-mail]> [e-mail] writes:
>>The most important is
>>guaranteed: that "the initialisation [...] in a translation unit is
>>done before the first use of any function or object defined in that
>>translation unit".
>
>    This is not guarranteed at all, even if it says it is!

Right.  I never understood why the ARM says that.  Maybe r3.4 should
instead read:

    the initialisation [...] in a translation unit is done before the
    first use **(not related to the initialization of another static
    object)** of any function or object defined in that translation unit

>>There remains the "pathologic" case of mutual
>>dependencies, dealt with in the annotation part of the ARM for 3.4,
>
>    This is not how it works. There is no general solution
>to the problem, so no algorithms can be written to solve it.

Right, there's no solution to:
    //file one.cpp
    extern int y;
    int x = y+1;
    //file two.cpp
    int y = x +1;

but Marc may be referring to the situation where the initialization of
one static uses another static object (eg, it uses a global
'error_log' stream).  The ARM commentary demonstrates the
'nifty-counter' technique which would require a file-scope static
object in the error_log.h file that would initialize the global
error_log.  One thing the ARM doesn't mention about this technique is
that the constructor used for the 'error_log' definition must *not*
modify the object since it may be called *after* one of the static
initializers initializes 'error_log'. (err, is that clear?)

>    Typically, what happens is static variables are initialised
>to a constant value first (0 if not otherwise specified)

I have a question about this.  The ARM seems to only guarantee that
static objects are initialized to 0 before any dynamic initializations.
(I assume this does not necessarily mean all-bits-zero in the case of
pointers and floats/doubles).  Does that mean there's no guarantee that
'x' below will be 5 during the construction of a static in another file?
    int x = 5;  // 'x' is a global

Btw, I believe even the following is considered a dynamic initialization:
    int x;
    int* p = &x;
and therefore there's no guarantee that 'p' points to 'x' during the
construction of other globals.

>then modules get initialised in the order of linkage,
>and variables in each module in the order of writing.

I hope the Working Papers have clarified 3.4.  Can someone with access
please outline the changes?

Thanks, Jamshid Afshar
[e-mail]