Re: Functional Local Static Zero Initialization - When?
On Dec 5, 7:02 pm, Brian Cole <col...@gmail.com> wrote:
On Dec 5, 2:22 am, James Kanze <james.ka...@gmail.com> wrote:
On Dec 5, 3:38 am, Brian Cole <col...@gmail.com> wrote:
A working draft of the C++ standard I was able to obtain
says the following in section 6.7.4: The
zero-initialization (8.5) of all local objects with static
storage duration (3.7.1) or thread storage duration
(3.7.2) is performed before any other initialization takes
place. First, the only addition for C++0x is the thread
storage duration, so I assume the sentence was the
following for previous versions of the standard: The
zero-initialization (8.5) of all local objects with static
storage duration (3.7.1) is performed before any other
initialization takes place. The criteria "before any
other initialization" is a little ambiguous here. Does
this mean any other initialization inside the function the
static resides, or any other initialization the entire
program may perform.
I don't see any ambiguity. "Before any other
initialization" means "before any other initialization".
I guess the ambiguity is in my own mind fueled by the rest of
the paragraph:
"A local object of trivial or literal type (3.9) with static
or thread storage duration initialized with
constant-expressions is initialized before its block is =EF=AC=81rst
entered."
Hinting that the zero-initialization could occur after main is
invoked as long as it's before the function is entered.
Because, basically, a conforming program can't tell the
difference. There's no way to access a local object before the
function has been entered.
The next sentence only says the implementation is "permitted"
to perform initialization before main, doesn't seem to require
it:
"An implementation is permitted to perform early
initialization of other local objects with static or thread
storage duration under the same conditions that an
implementation is permitted to statically initialize an object
with static or thread storage duration in namespace scope
(3.6.2)."
I am willing to accept that any decent compiler implementation
would zero out all the memory defined for function local
statics during "zero-initialization" since that would be
cheaper than doing it during main. Just wanted to be sure. Any
idea what standard this guarantee first appeared in? I deal
with some rather old compilers sometimes.
The rules concerning zero initialization and static
initialization of PODs are taken directly from the C standard,
and go back to Kernighan and Richie. And although I've heard of
some odd pre-standard C compilers which didn't follow them, I
think you can feel safe with any compiler later than about
1985/1990, and with any C++ compiler. (I've used all of the C++
compilers which were available before 1990.)
[...]
It will be if the object has static storage duration.
Otherwise not.
So the next obvious question is if there is a way I can force
users of the class to always declare it "static" since the
implementation will depend on this condition.
Attention: what is required is static storage duration. That
has nothing to do with the keyword static. Defining it at
namespace scope is sufficient.
Since static is a storage class specifier and has nothing to
do with the type there is no fancy typedef trickery I could do
to catch the following misuse of the class:
Foo *GetMeyersSingletonFoo()
{
Once<Foo> foo;
return foo;
}
The only hope is that during testing that foo would get placed
in some memory on the stack that wasn't already zero'd out,
triggering an assertion in the constructor. Seeing that memory
is often zero'd out for various reasons it seems way to easy
for this to fall through testing and only appear in production
down the road.
Can any C++ wizards think of a way to catch this at compile or
run time?
You can easily require dynamic allocation, by making the
destructor private, but I don't know off hand of any way of
requiring static lifetime. (On some specific machines, I know
ways of catching the error at runtime: on a Sparc under Solaris
or a PC under Linux, for example, there is a global symbol int
end; any address less than the address of this symbol is in
namespace scope. But that doesn't work on many other systems.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=C3=A9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=C3=A9mard, 78210 St.-Cyr-l'=C3=89cole, France, +33 (0)1 30 23 00 =
34