Re: initialization order of function local static variables
* Severin Ecker:
Hi Alf,
On 10.03.2010 08:20, Alf P. Steinbach wrote:
Now, if Foo and Bar are PODs, reading the C++ standard section 6.7.4,
an implemenation is free to zero initialize foo and bar during the
static initialization process before the program flow enters main()
and therefore before either x() or y() are invoked? (and as such,
reading the rules from 3.6.2, the order whether foo or bar will be
initialized first is not specified.) Am I right thus far?
I think so, yes. But note that this is zero initialization. Which is a
distinct phase from dynamic initialization.
I think this also applies to constant initialization from what i read here.
Now consider that Bar and Foo are classes with a non-trivial default
constructors (but constructors that are independent of the other class
as this would probably trigger one of the rules in 3.6.2), what's the
situation there? Will the local variables only be initialized (namely
the constructor be called) when the program flow reaches the local
variable definitions in x() and y() respectively
Yes.
or is the compiler still allowed to perform early initialization?
It was never allowed to do early initialization in general. Static zero
initialization is a distinct phase from dynamic initialization like
calling constructors. The dynamic initialization is (in the case we're
considering) performed when the execution first passes through the
declarations. This is the basis of lazily constructed Meyers' singletons.
In that case I don't quite understand 3.6.2/2
"An implementation is permitted to perform the initialization of an
object of namespace scope with static storage duration as a static
initialization even if such initialization is not required to be done
statically, provided that
- the dynamic version of the initialization does not change the value
of any other object of namespace scope with static storage duration
prior to its initialization"
The key is "namespace scope".
In your example
void x() {
static Foo foo;
}
the object "foo" is not at namespace scope -- it's a local object of static
storage duration, as opposed to a namespace scope object of static storage
duration, which is why the wording above contains both phrases, "namespace
scope" and "static storage duration".
Does "dynamic version of the initialization" here refer to "being
initialized, once the program flow reaches said statement", or would
this also include a dynamic initializer like a constructor call.
At namespace scope it's not meaningful to talk about the program flow reaching
the statement.
But for a local object it is meaningful to talk about that (and the standard does).
Still the order of destruction must be the exact opposite of the order
of construction (even when early initialization is applied and
therefore "ignoring" which function was called first), yes?
Yes.
One additional question to this: is the order of initialization of
objects with statid storage duration "implementation defined" or
"unspecified" (I guess, relying on the order itself yields undefined
behaviour, correct?)
I'm guessing that you're asking about the aspects that aren't well
specified, like the static initialization fiasco; if so, I don't know
the exact wording, because IMHO it would not be a good idea to rely on a
given compiler's rules even if they were well documented and defined.
Well in fact this all boils down to checking whether one of the
compilers (gcc) we're using is buggy in terms of order of destruction
for function local objects with static storage duration (which i doubt
personally), or if the compiler in fact is allowed to do early
initialization and then all bets are off on the order and we can't rely
on the objects being created in the order that the functions which
contain them are being called (msvc seems not to do any early
initialization in this case).
Hm, do you have a concrete example?
Anyway, if it is a real problem then I suggest looking in Andrei's "Modern C++
Design" -- or just the Loki library -- for singletons with destruction
policies and even resurrection-as-needed (a.k.a. Phoenix) functionality. ;-)
many thanks again and cheers,
severin
Cheers,
- Alf