Re: static functions

["Jody Hagins" <gamecox@magicnet.net>]

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


See my followup I posted a few minutes ago.  Actually, I *was* trying to
talk about C++, with old C being hat was familiar to the questioner.

[SNIP]

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

I agree that it can be misleading, but it is there to reinforce the idea
that it's not necessarily the main thread that does the construction, if
another thread reaches the function first.  statics are definitely *not*
per-thread data.

[SNIP]

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

Cool.  I was in the OS writing business for years (first successful SMP
SVR4 implementation).

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


I actually wrote the image loader for aforementioned operating system.  I
say that the compiler initializes variables, because what you said is what
happens, they get placed in a segment that is defined as zero.  Since I'm
not too familiar with PC compilers/OS, I'll tell you what happens in the
unix world (which should be similar... sound like it).

When an image is loaded, it's mmap-ed (memory mapped).  Since the entire
bss section of the file is already zero (done by the compiler -- or maybe
linker -- can't remember), all that happens is it gets mmapped into some
virtual address.  No code is actually run to initialize the memory to zero
at all.  Now, the PC side may be different, but only in the manner in which
the BSS is loaded.  Once it's loaded its gonna be all zeroes.

As stated before, my example was poor, because

void foo()
{
  static int i = 1;
}

isn't guaranteed to be set to 1 until foo() runs.  In fact, for objects,
ctors definitely won't run until the first time foo() is encountered.

So, either way, the object is never initialized until foo() runs.  All
objects static or global are initially located into zero based memory, so I
don't call that initialization, at least not explicit initialization
(though I do take advantage of knowing that all such data is zero when I
first encounter it.


I guess I've overdone my geek status too.

	-jody