Re: static functions

["Scott Pace" <space@vistar.ca>]

-----Original Message-----
From: Ken Paul <ken@rbl.reno.nv.us>
To: cpb-thread@zdtips.com <cpb-thread@zdtips.com>
Date: Friday, March 06, 1998 1:02 PM
Subject: Re: static functions


>>>int anotherFunction()
>>>{
>>>  static int beenHere; // declared in same memory segment as "foofoo"
>>>                       // but is only available to this function.  It
>>>                       // is not on the stack, and retains its value
>>>                       // between invocations of this function.  Also, it
>>>                       // is not initialized until the first call to
>>>                       // this function.
>>>}
>>>
>>
>>
>>Not true. Because it is static, by definition it will be initialized to 0
>>(zero) before main() is called.
>>
>>Cheers,
>>Scott.
>
>Actually, the first description is correct. Static locals only get
>initialized/constructed when the thread of execution passes through them
>for the first time. They are destroyed/destructed when the program exits.
>(see The C++ Programming Language, 3rd ed., Bjarne Stroustrup, section
>10.4.8 - Local Static Store, pg 251.)
>


Again, I disagree. The section that you reference talks about *objects* with
ctors/dtors. Not about simple types. With objects, knowing when an object
gets constructed can be important.

On the other hand, you might want to look at section 7.1.2 page 145 where it
does indeed support your argument.

However, in the original article, Jody was giving an example of C usage of
statics, and then C++ usage. I still say that I am correct regarding local
static initialization in C...

Section 4.9 on page 85 of The C Programming Language 2nd Edition by K&R
says:

"For external and static variables, the initializer must be a constant
expression; the initialization is done once, conceptually before the program
begins execution."

No distinction is made for local vs. non-local statics.

>Static globals are, however, initialized as Scott described...
>

Finally, I believe that the way Stroustrup talks about static locals and how
they are initialized only when the thread of execution passes them (for the
1st time) can be misleading to inexperienced designers:

- The phrase "thread of execution" might suggest to some that static locals
are initialized on a per thread basis. This, of course, would be an
incorrect assumption, since static locals are not thread safe (without
programmer intervention).

- Although Stroustrup says that static locals are first initialized when the
thread of execution reaches them, this is conceptual only. In reality,
(having been in the compiler writing business myself), no compiler would
implement them that way. Instead, they would continue the C approach of
putting all uninitialized globals and statics in a sequential block of
memory, often called the BSS segment, and then use the equivalent of a call
to memset() to set it all to zero before main() is called. Much more
efficient, and still achieves the desired effect and works as expected for
the programmer and his code. Of course, this only applies to standard C
datatypes. Objects behave as described in section 10.4.8.

Actually, a lot of OS's today will do the BSS (zero) initialization for the
program. Borland C++ Builder still includes the code to do it in the startup
assembler module. If you're interested, search for the file c0nt.asm on the
cdrom. Then look at the section in that file starting on line 365. That's
where the startup code initializes the BSS segment to all 0. You can bet
that static locals (not objects) will be in the BSS segment, if they haven't
been explicitly initialized in the C code.

Well, that's filled my geek-out quota for the week :-)

Cheers,
Scott.