Re: zero initialization.
On Dec 20, 12:51 pm, werasm <wer...@gmail.com> wrote:
On Dec 20, 10:31 am, James Kanze <james.ka...@gmail.com> wrote:
There are also special cases where you count on zero
initialization to detect that dynamic initialization hasn't
occured yet (in order to manage order of initialization). In
such cases, you obviously can't make the zero initialization
explicit.
Could you perhaps (please) elaborate on the adverse effects of
making zero initialization explicit in the last case
mentioned. It is still not so obvious to me.
The main adverse effect is that it isn't possible to do it.
Consider something like:
Singleton* Singleton::ourInstance = &Singleton::instance() ;
Singleton&
Singleton::instance()
{
if ( ourInstance == NULL ) {
ourInstance = new Singleton ;
}
return *ourInstance ;
}
In this case, the dynamic initialization is to ensure that
Singleton::instance is called at least once before main is
entered. And thus, presumably, before threading starts and we
need a lock. In other cases, you may simply want to test
whether dynamic initialization has taken place or not.
You can, of course, always explicitly initialize with null, and
then use some other trick to trigger the dynamic initialization,
e.g. something like:
Singleton* Singleton::ourInstance = NULL ;
bool thisVariableIsNeverUsed
= (Singleton::instance(), true) ;
Singleton&
Singleton::instance()
{
if ( ourInstance == NULL ) {
ourInstance = new Singleton ;
}
return *ourInstance ;
}
I would hope, however, that the fact that variables with static
lifetime are zero initialized is widely enough known that such
extra trickiness (which IMHO doesn't make the code clearer in
the least) not be necessary.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34