where/when should I initialize static class data members?

R

r.z.

They should be initialized before any instance is created. I have no idea in
which file, in which place should I put their initialization code to be sure
they are initialize only once, before any instance is created.
I cannot visualize the control flow of an executing program when the code is
split in multiple files.
 
M

Marcus Kwok

r.z. said:
They should be initialized before any instance is created. I have no idea in
which file, in which place should I put their initialization code to be sure
they are initialize only once, before any instance is created.
I cannot visualize the control flow of an executing program when the code is
split in multiple files.

This sounds like it might be a case of the "static initialization order
fiasco". Maybe this entry (and the ones following it) in the FAQ can
provide some insight:

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12
 
M

mlimber

They should be initialized before any instance is created. I have no idea in
which file, in which place should I put their initialization code to be sure
they are initialize only once, before any instance is created.
I cannot visualize the control flow of an executing program when the code is
split in multiple files.

Except for integral constants, which may be initialized in the class
definition, you generally want them in the .cpp file associated with
your .hpp file. If the code for a class needs to be split into
multiple .cpp files, that may be an indication that your class is too
big and is doing to much (time to refactor!). The code to initialize
static vars gets run automatically and only once before main()
executes. Often order of initialization doesn't matter, but if it
does, there are some subtle problems that can crop up. See this FAQ
and those following:

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12

Cheers! --M
 
R

red floyd

Marcus said:
This sounds like it might be a case of the "static initialization order
fiasco". Maybe this entry (and the ones following it) in the FAQ can
provide some insight:

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12

Now, I'm concerned on my own code. Will I hit the initialization order
fiasco on this code?

// A.h

class B;
class A {
private:
static B x;
public:
static void f();
};

// A.cpp

#include "A.h"
#include "B.h" // details irrelevant, assume
// void B::do_something() exists

B A::x;

void A::f()
{
x.do_something();
// do other stuff
}

// main.cpp

#include "A.h"

int main()
{
A::f();
}
 
P

pawel_kunio

They should be initialized before any instance is created. I have no idea in
which file, in which place should I put their initialization code to be sure
they are initialize only once, before any instance is created.
I cannot visualize the control flow of an executing program when the code is
split in multiple files.

One of possibilities is if the references to static are local to
single function/single cpp file, the var should be defined in that
file.
 
G

Gavin Deane

Now, I'm concerned on my own code. Will I hit the initialization order
fiasco on this code?

No. The static initialisation order fiasco is an issue when you have
*two* different static objects (e.g. obj1 and obj2) defined in
*different* source files *and* your code relies on one being
constructed before the other (e.g. during construction of obj1, obj1
calls a member function obj2). The problem is that there is no way you
can control which of obj1 and obj2 is constructed first, but if obj1
happens to be constructed first there is no obj2 yet for it to use.
Bang - you're dead.

Your code below only contains one static object, A::x, of type B.
// A.h

class B;
class A {
private:
static B x;
public:
static void f();

};

// A.cpp

#include "A.h"
#include "B.h" // details irrelevant, assume
// void B::do_something() exists

B A::x;

void A::f()
{
x.do_something();
// do other stuff

}

// main.cpp

#include "A.h"

int main()
{

It is guaranteed that, by the time you enter main here, A::x is fully
constructed, therefore the call to A::f() below, which in turn calls a
member function of A::x, is fine.
A::f();
}

What would be a problem would be if you had something like this (not
tested):

// C.h
#include "A.h"
class C
{
public:
// Constructor indirectly calls do_something() on A::x
C() { A::f(); }
};

and you changed main.cpp to

#include "A.h"
#include "C.h"

C c;

int main()
{
A::f();
}

Now A::x and c are defined in different translation units and you have
no control over which is constructed first. But the construction of c
involves calling do_something() on A::x. So if the compiler happens to
choose to construct c first, you suffer death by fiasco.

Gavin Deane
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top